Group management method, device and electronic equipment

Abstract

The application relates to a group management method and device and electronic equipment, wherein the method comprises the following steps: after a group message is published, signature information of any group member is received; the group message and the signature information are verified to obtain a first verification result, and whether fraud exists in the signature process is determined in combination with the first verification result and the group message of the group; if fraud exists, the group member corresponding to the signature information is determined, the group member is added to a revocation list, and the group member is deleted from the group. Thus, the technical problems that, in the related art, the trend of decentralized privacy protection is contrary, it is inconvenient to combine with technologies such as blockchains, the revocation cost is high, and it is difficult to trace, and the like are solved.

Description

Technical Field

[0001] This application relates to the field of information security technology, and in particular to a group management method, apparatus and electronic device. Background Technology

[0002] Digital signature technology is an important cryptographic method used to verify message integrity and prevent forgery. As part of the public key infrastructure, it is widely used in various scenarios of our daily lives. By using the signer's private key and a hash function, digital signatures can append additional information or encrypt message data units, enabling the recipient to verify the source of the data and ensure its integrity and authenticity. Depending on different application needs, digital signature technology has evolved into various forms, including group signatures, ring signatures, blind signatures, and identity-based signatures.

[0003] Group signatures (GS) are a cryptographic technique that allows any member of a group to sign a message on behalf of the entire group, while protecting the signer's identity from outside knowledge. Only the group administrator can reveal the signer's identity when necessary. While protecting privacy, group signature technology ensures the legitimacy and authenticity of the signature, and is widely used in scenarios requiring anonymity but trust, such as electronic voting and anonymous transactions. However, because ordinary group signatures involve a group administrator whose identity can be traced, this contradicts the trend of decentralized privacy protection and is not easily integrated with technologies such as blockchain. Furthermore, revoking a user's action will require other users who have not revoked to update their keys, causing unnecessary additional overhead and hindering its application on large user platforms. On the other hand, complete anonymity makes it very difficult for users to link their historical signatures when needed in the future, which needs improvement. Summary of the Invention

[0004] This application provides a group management method, device, and electronic device to solve the technical problems in related technologies, such as being contrary to the trend of decentralized privacy protection, not being easy to combine with technologies such as blockchain, and having high revocation costs and difficulty in tracing.

[0005] The first aspect of this application provides a group management method, including the following steps: after publishing a group message, receiving signature information of any group member; verifying the group message and the signature information to obtain a first verification result, and determining whether there is fraudulent activity in the signature process by combining the first verification result and the group message of the group; if there is fraudulent activity, identifying the group member corresponding to the signature information, and adding the group member to the revocation list to delete the group member from the group.

[0006] Optionally, in one embodiment of this application, the method further includes: determining the upper limit of the number of group members, the upper limit of the number of events, the hash function, and the binary conversion function of the group based on preset security parameters and calculation parameters; initializing group data, and combining the initialized group data, the security parameters, the calculation parameters, the upper limit of the number of group members, the upper limit of the number of events, the hash function, and the binary conversion function to output a common parameter set to complete the initialization of the group.

[0007] Optionally, in one embodiment of this application, after the initialization of the group is completed, the method further includes: outputting a group key pair using a trapdoor generation algorithm; receiving a locally generated user key pair and a group joining request from a user; responding to the user's group joining request by combining the group key pair and the user key pair, and updating the group information of the group.

[0008] Optionally, in one embodiment of this application, after updating the group information, the method further includes: receiving a data update request from a group administrator; in response to the data update request, determining whether the group's revocation list is empty; if the revocation list is empty, verifying whether the user identifier of each group member in the group has completed the user counter accumulation, obtaining a second verification result, and publishing the updated group information based on the second verification result; if the revocation list is not empty, using the key corresponding to the identity identifier of the revoked group member in the revocation list as an index, searching for the corresponding user tuple in the group's registration list, and setting the user tuple to zero to complete the revocation of the group member.

[0009] Optionally, in one embodiment of this application, before receiving the signature information of any group of members, the method further includes: encrypting the relevant group recovery threshold of the any group of members to obtain an encrypted value; calculating the hash value and pseudonym of the any group of members using a hash function; generating a non-interactive zero-knowledge proof for verifying the any group of members using the hash value, the pseudonym, and the encrypted value; and obtaining the signature information of the any group of members that satisfies a preset verifiable condition using the non-interactive zero-knowledge proof.

[0010] Optionally, in one embodiment of this application, after generating a non-interactive zero-knowledge proof for verifying the members of the group, the method further includes: verifying whether the non-interactive zero-knowledge proof satisfies a preset validity condition; if the preset validity condition is satisfied, then using the non-interactive zero-knowledge proof to obtain the signature information of the members of the group that satisfies the preset verifiable condition.

[0011] Optionally, in one embodiment of this application, the verification of the group message and the signature information includes: obtaining the latest accumulated value of the group, and using the latest accumulated value to parse the signature information to obtain signature parameters; using multiple hash functions to verify the signature parameters in sequence, and if the verification is successful, determining whether the revocation list contains any group member; if it contains any group member, determining that the signature information is invalid and ending the current signature process; otherwise, determining whether there is fraudulent activity in the signature process based on the first verification result.

[0012] Optionally, in one embodiment of this application, determining whether fraudulent activity exists in the signature process by combining the first verification result and the group message of the group includes: obtaining any two signature information within the group; verifying the legality of the two signature information respectively, and if both signature information is legal, parsing the two signature information respectively to obtain the pseudonym and associated group message corresponding to each signature information; and determining whether fraudulent activity exists based on the pseudonym and the group message.

[0013] A second aspect of this application provides a group management device, comprising: a first receiving module, configured to receive signature information of any group member after a group message is published; a first verification module, configured to verify the group message and the signature information to obtain a first verification result, and to determine whether fraudulent activity exists in the signature process by combining the first verification result and the group message; and a first revocation module, configured to, if fraudulent activity exists, determine the group member corresponding to the signature information and add the group member to a revocation list to delete the group member from the group.

[0014] Optionally, in one embodiment of this application, it further includes: a determining module, configured to determine the upper limit of the number of group members, the upper limit of the number of events, the hash function, and the binary conversion function of the group according to preset security parameters and calculation parameters; and an initialization module, configured to initialize group data and output a common parameter set by combining the initialized group data, the security parameters, the calculation parameters, the upper limit of the number of group members, the upper limit of the number of events, the hash function, and the binary conversion function to complete the initialization of the group.

[0015] Optionally, in one embodiment of this application, it further includes: an output module, configured to output a group key pair using a trapdoor generation algorithm; a second receiving module, configured to receive a locally generated user key pair and a group joining request from a user; and an update module, configured to respond to the user's group joining request by combining the group key pair and the user key pair, and update the group information of the group.

[0016] Optionally, in one embodiment of this application, it further includes: a third receiving module, configured to receive a data update request from a group administrator; a judging module, configured to, in response to the data update request, judge whether the group's revocation list is an empty set; a second verification module, configured to, if the revocation list is an empty set, verify whether the user identifier of each group member in the group has completed the user counter accumulation, obtain a second verification result, and publish updated group information based on the second verification result; and a second revocation module, configured to, if the revocation list is not an empty set, use the key corresponding to the identity identifier of the revoked group member in the revocation list as an index to find the corresponding user tuple in the group's registration list, and set the user tuple to zero to complete the revocation of the group member.

[0017] Optionally, in one embodiment of this application, it further includes: an encryption module, used to encrypt the relevant group recovery threshold of the members of any group to obtain an encrypted value; a calculation module, used to calculate the hash value and pseudonym of the members of any group using a hash function; a generation module, used to generate a non-interactive zero-knowledge proof for verifying the members of any group using the hash value, the pseudonym and the encrypted value; and a first acquisition module, used to obtain the signature information of the members of any group that meets the preset verifiable conditions using the non-interactive zero-knowledge proof.

[0018] Optionally, in one embodiment of this application, it further includes: a third verification module, used to verify whether the non-interactive zero-knowledge proof meets a preset validity condition; and a second acquisition module, used to obtain the signature information of any group of members that meet the preset verifiable condition using the non-interactive zero-knowledge proof if the preset validity condition is met.

[0019] Optionally, in one embodiment of this application, the first verification module includes: a first acquisition unit, configured to acquire the latest accumulated value of the group and parse the signature information using the latest accumulated value to obtain signature parameters; a first verification unit, configured to sequentially verify the signature parameters using multiple hash functions, and if the verification is successful, determine whether the revocation list contains any group member; and a first determination unit, configured to determine that the signature information is invalid and terminate the current signature process if the signature information contains any group member, otherwise, determine whether fraudulent activity exists in the signature process based on the first verification result.

[0020] Optionally, in one embodiment of this application, the first revocation module includes: a second acquisition unit, configured to acquire any two signature information within the group; a second verification unit, configured to verify the legality of the two signature information respectively, and, if both signature information are legal, parse the two signature information respectively to obtain a pseudonym and associated group message corresponding to each signature information; and a second determination unit, configured to determine whether the fraudulent activity exists based on the pseudonym and the group message.

[0021] A third aspect of this application provides an electronic device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the group management method as described in the above embodiments.

[0022] A fourth aspect of this application provides a computer-readable storage medium storing computer instructions for causing the computer to perform the group management method as described in the above embodiments.

[0023] A fifth aspect of this application provides a computer program product, including a computer program that, when executed, implements the group management method described above.

[0024] This application embodiment can receive signature information from any group member after publishing a group message, and verify the group message and signature information. Based on the first verification result and the group message, it determines whether there is fraudulent activity in the signature process. If fraudulent activity is found, the group member corresponding to the signature information is identified and added to the revocation list to remove the group member. The revocation process has no impact on other users who have not revoked, and avoids malicious revocation. It satisfies the requirements of selfless anonymity, traceability, and non-defamation, and is applicable to scenarios such as the Internet of Things, finance, and digital healthcare. Therefore, it solves the technical problems in related technologies, such as contradicting the trend of decentralized privacy protection, being inconvenient to combine with technologies such as blockchain, and having high revocation costs and difficulty in traceability.

[0025] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0026] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein:

[0027] Figure 1 This is a flowchart illustrating a group management method according to an embodiment of this application;

[0028] Figure 2 This is a flowchart illustrating a signature generation process according to one embodiment of the present application;

[0029] Figure 3 This is a flowchart illustrating a signature verification process according to an embodiment of this application.

[0030] Figure 4 This is a schematic diagram of a group management device according to an embodiment of this application;

[0031] Figure 5 This is a schematic diagram of the structure of an electronic device provided according to an embodiment of this application. Detailed Implementation

[0032] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0033] The following description, with reference to the accompanying drawings, describes a group management method, apparatus, and electronic device according to embodiments of this application. Addressing the technical problems mentioned in the background art, such as contradicting the trend of decentralized privacy protection, being inconvenient to integrate with technologies like blockchain, and having high revocation costs and difficulty in traceability, this application provides a group management method. In this method, after publishing a group message, signature information from any group member can be received, and the group message and signature information can be verified. Based on the first verification result and the group message, it is determined whether fraudulent activity exists in the signature process. If fraudulent activity exists, the group member corresponding to the signature information is identified, and the group member is added to the revocation list to remove the group member. The revocation process has no impact on other users who have not revoked, and malicious revocation is avoided. It satisfies the requirements of anonymity, traceability, and non-defamation, and is applicable to scenarios such as the Internet of Things, finance, and digital healthcare. Therefore, this method solves the technical problems in related technologies, such as contradicting the trend of decentralized privacy protection, being inconvenient to integrate with technologies like blockchain, and having high revocation costs and difficulty in traceability.

[0034] Specifically, Figure 1 This is a flowchart illustrating a group management method provided in an embodiment of this application.

[0035] like Figure 1 As shown, the management method for this group includes the following steps:

[0036] In step S101, after publishing the group message, the signature information of any group member is received.

[0037] The method proposed in this application has the characteristics of user-initiated group signing and validator-conditional revocation. In this application embodiment, it can support users dynamically joining groups, and restrict each group member to signing only one message under the same event topic; otherwise, a revocation condition is triggered, which allows the validator to easily extract the user's revocation token and add it to the revocation list. The revocation process has no impact on other users who have not revoked. The construction of this application embodiment relies on a Stern-class protocol Kimek tree accumulator, and the final signature size is logarithmically related to the group size.

[0038] In actual implementation, this application embodiment can receive the signatures of any group member in the group after publishing group messages, such as after the group message is updated, so as to perform signature verification later.

[0039] Optionally, in one embodiment of this application, the method further includes: determining the upper limit of the number of group members, the upper limit of the number of events, the hash function, and the binary conversion function of the group based on preset security parameters and calculation parameters; initializing group data, and combining the initialized group data, security parameters, calculation parameters, upper limit of the number of group members, upper limit of the number of events, hash function, and binary conversion function to output a common parameter set to complete the initialization of the group.

[0040] During the initial construction of the group, embodiments of this application can set encryption protocols for the group, determine group signature or threshold signature schemes, and involve various parameters and functions to ensure security and efficiency.

[0041] In actual implementation, the embodiments of this application can input parameters: security parameter λ, positive integers n, m, q, p, σ, k, ι, where,

[0042] Where λ is a security parameter used to determine the overall security level of the system, n is a lattice parameter, m is a lattice parameter, p and q are prime numbers, and k is a lattice parameter, satisfying... ι is the lattice parameter, κ is the lattice parameter, and σ is the Gaussian distribution parameter.

[0043] This application embodiment can also limit the group size: setting the maximum number of group members to be [value].

[0044] N=2 ι =poly(λ), scp∈{0,1} * The upper limit of the quantity is Q, which satisfies Q << p.

[0045] Where N is the maximum number of group members, Q is the maximum number of event topics, and scp is the event topic.

[0046] This application embodiment can also define a hash function: selecting hash function H1: H2:

[0047] This application embodiment can also define tool matrices G1 and G2, and define a binary conversion function bin:

[0048] in, Let bin be an integer vector space of length n, and bin be the binary conversion function bin:

[0049] In actual implementation, group administrators You can initialize a Merkle tree using TSetup(pp,gpk) → Τ crt Set all leaf nodes to 0, initialize the user counter c = 0, and initialize the cancellation list. The initial user registration list is reg({[i][grt[i]][upk[i]]} i∈[N] )={[i][0 m ][0 nk The set of common parameters of the output system is pp={λ,n,m,q,p,σ,k,N,Q,H1,H2,G1,G2,ι}.

[0050] The above setup phase lays the foundation for subsequent operations such as user registration, signature generation, and verification.

[0051] Optionally, in one embodiment of this application, after the group initialization is completed, the method further includes: outputting a group key pair using a trapdoor generation algorithm; receiving a locally generated user key pair and a group joining request from a user; responding to the user's group joining request by combining the group key pair and the user key pair, and updating the group information.

[0052] After initialization, this embodiment of the application can utilize a key generation protocol executed by the group administrator to create a key pair that can be shared by group members to achieve encryption, signing, or other security functions. On the user side, each user can independently generate their own key pair, thereby enabling encryption and decryption in group communication or collaboration while maintaining data security and privacy.

[0053] This application embodiment enables user joining through interaction between the user and the group administrator, utilizing group keys and user keys. This allows the user to officially become a member of the group and update the group's status and related parameters accordingly. This process ensures the group's security and integrity while also providing users with necessary authentication information.

[0054] For example, the following algorithm can be used in the embodiments of this application:

[0055] GKeyGen(pp,gpk): Administrator Execute, run (A,T) A )←TrapGen(1 n ,1 m ,q,I), output group key pair (gsk,gpk)=(T A A),

[0056] UKeyGen(pp, gpk): Executed locally by the user, running (b, T b )←TrapGen(1 n ,q,I), select x←{0,1} m (x≠0), calculate Output the user's key pair (usk,upk) = (T b ,x,b,d).

[0057] This is conducted interactively between the user and the group administrator.

[0058] user: Sends a request to join the group by sending upk=(b,d);

[0059] GM: If the request is approved, publish user ID j = bin(c) and run. Set usk[j] = (T b ,x,s,j),grt[i]=s is sent to the user; the tree T is updated. crt Calculate the new accumulated value Tupdate A (j,d)→z new Update the user counter c+=1; Update the user registration list reg=({[j][s][d]}).

[0060] After key verification, this embodiment of the application can respond to the user's request to join the group and update the group information.

[0061] Optionally, in one embodiment of this application, after updating the group information, the method further includes: receiving a data update request from the group administrator; in response to the data update request, determining whether the group's revocation list is empty; if the revocation list is empty, verifying whether the user identifier of each group member in the group has completed the user counter accumulation, obtaining a second verification result, and publishing the updated group information based on the second verification result; if the revocation list is not empty, using the key corresponding to the identity identifier of the revoked group member in the revocation list as an index, searching for the corresponding user tuple in the group's registration list, and setting the user tuple to zero to complete the revocation of the group member.

[0062] Furthermore, embodiments of this application can also perform group updates, executed by the group administrator, to maintain the dynamic state of the group, including removing violating members and updating the group's public parameters.

[0063] For example, the data update in this application embodiment can be implemented based on the following algorithm:

[0064] GUpdate(gpk,gsk): Administered by the group administrator. implement.

[0065] a. If Then proceed to step b. Otherwise, using grt[j] = s as the index, find the corresponding user tuple in the registration list reg and set the corresponding upk[j] = 0 to zero;

[0066] b. For each j, let As evidence, d i It has been accumulated to z new In the middle, publish group message info new =(z new ,{w j} j∈[c] ).

[0067] This application embodiment enables group administrators to ensure the synchronization of group status, promptly reflect member changes, and maintain group transparency and security by executing the GUpdate algorithm. This not only handles member joining and leaving but also maintains the consistency and integrity of group data.

[0068] Optionally, in one embodiment of this application, before receiving the signature information of any group of members, the method further includes: encrypting the relevant group recovery threshold of any group of members to obtain an encrypted value; calculating the hash value and pseudonym of any group of members using a hash function; generating a non-interactive zero-knowledge proof for verifying any group of members using the hash value, pseudonym, and encrypted value; and obtaining the signature information of any group of members that meets the preset verifiable conditions using the non-interactive zero-knowledge proof.

[0069] As one possible implementation method, the user's signature process in this application embodiment may include: public key encryption, hash function, random number generation, homomorphic encryption, zero-knowledge proof and signature scheme.

[0070] For example, UCLink(Σ,usk)→Π L :Executed by an honest user holding private key x

[0071] Analysis of ∑→{(nym1,scp1),…,(nym i scp i )}i∈K K≤Q,

[0072] calculate

[0073] generate

[0074] Using the above method, this application embodiment can create a zero-knowledge proof that can demonstrate to others that the holder knows certain information (such as private key x) and can perform correct calculations based on that information, while not disclosing specific information details, thereby protecting user privacy.

[0075] Optionally, in one embodiment of this application, after generating a non-interactive zero-knowledge proof for verifying any group of members, the method further includes: verifying whether the non-interactive zero-knowledge proof satisfies a preset validity condition; if the preset validity condition is satisfied, then using the non-interactive zero-knowledge proof to obtain the signature information of any group of members that satisfies the preset verifiable condition.

[0076] In actual implementation, the embodiments of this application can use steps such as analysis of the signature set, verification of the signature, and final check to verify whether the non-interactive zero-knowledge proof is effective.

[0077] For example,

[0078] Analysis of ∑→{(nym1,scp1),…,(nym i scp i )} i∈K K≤Q,

[0079] The Verify algorithm is run to verify each Σ one by one. i The validity of , if there exists Σ∈∑, Verify(gpk,pp,info) new ,Σ,RL)=0, return 0.

[0080] If for scp exists i =scp j Returns 0.

[0081] calculate Verification ||Δ|| ∞ Does ≤K+1 hold true? If true, output 1 to represent Π. L Valid; otherwise, output 0.

[0082] In summary, the embodiments of this application can ensure the integrity of the signature set and the validity of non-interactive zero-knowledge proofs through the above verification mechanism.

[0083] In step S102, the group message and signature information are verified to obtain a first verification result, and the first verification result and the group message of the group are combined to determine whether there is fraudulent activity in the signature process.

[0084] As one possible implementation, embodiments of this application can determine whether there is fraudulent activity in the signing process by verifying group messages and signature information, so as to avoid users on the revocation list signing or potential violations such as double-spending or other types of fraudulent activities.

[0085] Optionally, in one embodiment of this application, verifying the group message and signature information includes: obtaining the latest accumulated value of the group and using the latest accumulated value to parse the signature information to obtain signature parameters; using multiple hash functions to verify the signature parameters in sequence, and if the verification is successful, determining whether the revocation list contains any group members; if it contains any group members, determining that the signature information is invalid and ending the current signature process; otherwise, determining whether there is fraudulent activity in the signature process based on the first verification result.

[0086] The embodiments of this application can utilize a verification algorithm to check the validity of the signature and confirm whether the message has been correctly signed, while ensuring that the signer is not in the blacklist (revocation list, RL).

[0087] For example, Verify(gpk,pp,info) new ,Σ,RL)→1 / 0,

[0088] Download the latest accumulated value z new Analyze Σ, calculate V′=H1(scp), H′=H2(scp||M),

[0089] run Verify proof Π. If valid, proceed to step 0; otherwise, output 0 and return.

[0090] For each grt[i]→s′ in RL j Check if it exists If it exists, return 0.

[0091] The embodiments of this application can ensure that only legitimate, unrevoked users can successfully verify their signatures, thereby increasing the security and integrity of the system.

[0092] Optionally, in one embodiment of this application, determining whether fraudulent activity exists in the signature process by combining the first verification result and the group message of the group includes: obtaining any two signature information in the group; verifying the legality of the two signature information respectively, and if both signature information is legal, parsing the two signature information respectively to obtain the pseudonym and associated group message corresponding to each signature information; and determining whether fraudulent activity exists based on the pseudonym and group message.

[0093] This application embodiment can identify and handle potential violations, such as double-spending or other types of fraudulent activities, by processing two signature sets (Σ1, Σ2).

[0094] For example, Extract(Σ1,Σ2)→grt[π * ] / ⊥,

[0095] Run the Verify algorithm to verify the validity of Σ1 and Σ2.

[0096] Analyze Σ1 and Σ2. If nym1=nym2∧M1≠M2, then proceed to step 0; otherwise, output ⊥.

[0097] Run the decryption algorithm PKE.Dec(u1-u2,ct)→grt′[π * [and reported it to the group administrator.] Join the RL to remove the member who violated the rules.

[0098] The embodiments of this application can ensure the legality of signatures while providing a rapid response mechanism to violations, thereby preventing fraud and protecting the system from abuse.

[0099] In step S103, if fraudulent activity is found, the group member corresponding to the signature information is identified and added to the revocation list to remove the group member from the group.

[0100] In summary, the embodiments of this application can identify the group member corresponding to the signature information and add the group member to the revocation list in cases of fraudulent activities or signature verification failure, so as to delete the group member from the group.

[0101] Combination Figure 2 and Figure 3 As shown, an embodiment is used to illustrate the working principle of the group management method of this application.

[0102] The group management method in this application embodiment supports users dynamically joining groups, and limits each group member to signing only one message under the same event topic; otherwise, a revocation condition is triggered, allowing the verifier to easily extract the user's revocation token and add it to the revocation list. The revocation process has no impact on other users who have not revoked. The construction of this application embodiment relies on a Stern-class protocol Kimmerk tree accumulator, and the final signature size is logarithmically related to the group size.

[0103] Combination Figure 2 and Figure 3 As shown, the scheme in this embodiment can consist of 10 polynomial-time algorithms (Setup, GKeyGen, UKeyGen, Join, GUpdate, Sign, Verify, Extract, UCLink, VLink), wherein... Figure 2 For the signature generation process, Figure 3 The signature verification process is described in detail below:

[0104] (1) Setup(1 λ ): Input security parameter λ, positive integers n, m, q, p, σ, k, ι, where, m = 2nk, and the maximum number of group members is set to N = 2. ι =poly(λ), scp∈{0,1} * The maximum number of hashes is Q, satisfying Q << p; select a hash function. H3:{0,1} * →{1,2,3} κ κ=ω(logλ), tool matrices G1,G2, and the binary conversion function bin is defined. Group administrator Initialize Merkle tree TSetup(pp,gpk)→Τ crt Set all leaf nodes to 0, initialize the user counter c = 0, and initialize the cancellation list. The initial user registration list is reg({[i][grt[i]][upk[i]]} i∈[N] )={[i][0 m ][0 nk The set of common parameters of the output system is pp={λ,n,m,q,p,σ,k,N,Q,H1,H2,G1,G2,ι}.

[0105] (2) GKeyGen(pp, gpk): by the group administrator Execute. Run (A,T) A )←TrapGen(1 n ,1 mOutput group key pair (q, I).

[0106] (3) UKeyGen(pp, gpk): Executed locally by the user. Run (b, T b )←TrapGen(1 n ,q,I), select x←{0,1} m (x≠0), calculate Output your own key pair (usk,upk) = (T b ,x,b,d).

[0107] (4) This is an interactive process between the user and the group administrator. The user sends a request to join the group with the expression upk = (b, d).

[0108] If the request is approved, then publish user ID j = bin(c) and run s←SamPre(T) A ,A,I,b,σ), Set usk[j] = (T b ,x,s,j),grt[i]=s is sent to the user; the tree T is updated. crt Calculate the new accumulated value Tupdate A (j,d)→z new Update the user counter c+=1; Update the user registration list reg=({[j][s][d]}).

[0109] (5) GUpdate(gpk,gsk): by the group administrator implement.

[0110] a. If If the condition is met, proceed to step 0; otherwise, using grt[j] = s as the index, find the corresponding user tuple in the registration list reg and set the corresponding upk[j] = 0 to zero.

[0111] b. For each j, let As evidence, d i It has been accumulated to z new In the middle, publish group message info new =(z new ,{w j} j∈[c] ).

[0112] (6)Sign(gpk,pp,usk[π],M∈{0,1} * ,scp,upk[π],grt[π]): Executed by user π.

[0113] a. Run PKE.Enc(b,s′) to encrypt grt[π]: randomly select r←{0,1} mk , bin(s) → s′; Calculate C1 = br T ,

[0114] b. Calculate V = H1(scp), H = H2(scp||M), and run u←SamPre(b,T) b ,I,V+H·G1,σ).

[0115] c. Calculate kana

[0116] d. Generate non-interactive zero-knowledge proof protocol Φ Explanation: (1) Holds valid x,s; (2) u generated in b is valid; (3) The encryption process of grt[π] is correct; (4) nym,τ is correctly calculated.

[0117] The proof is described in the following three parts:

[0118] Π1:

[0119]

[0120] Π3:

[0121]

[0122] The final generated proof Here, the public input is X = (A,u,scp,G1G2,nym,τ,ct,z) ne- ,H,V), secret input (s,x,b,d,(j,w) j ),r,s·r T ).

[0123] e. The signature sig = (Π, ct, u) is used to output the message-signature pair Σ = (sig, M, nym, τ, scp).

[0124] (7) Verify(gpk,pp,info) new ,Σ,RL)→1 / 0.

[0125] a. Download the latest accumulated value z new Analyze Σ, calculate V′=H1(scp), H′=H2(scp||M),

[0126] b. Run Verify proof Π. If valid, proceed to step c; otherwise, output 0 and return.

[0127] c. For each grt[i]→s′ in RL j Check if it exists If it exists, return 0.

[0128] (8) Extract(Σ1,Σ2)→grt[π * ] / ⊥.

[0129] a. Run the Verify algorithm to verify the validity of Σ1 and Σ2.

[0130] b. Analyze Σ1 and Σ2. If nym1=nym2∧M1≠M2, then proceed to step c; otherwise, output ⊥.

[0131] c. Run the decryption algorithm PKE.Dec(u1-u2,ct)→grt′[π * [and reported it to the group administrator.] Join the RL to remove the member who violated the rules.

[0132] (9)UCLink(Σ,usk)→Π L : Performed by an honest user who holds the private key x.

[0133] Analysis of Σ→{(nym1,scp1),…,(nym i scp i )} i∈K K≤Q,

[0134] calculate

[0135] Generate NIZK

[0136] (10)

[0137] Analysis of Σ→{(nym1,scp1),…,(nym i scp i )} i∈K ,K≤Q.

[0138] The Verify algorithm is run to verify each Σ one by one. i The validity of the expression is verified if Σ∈Σ, Verify(gpk,pp,info) new If ,Σ,RL)=0, return 0.

[0139] If for scp exists i =scp j Returns 0.

[0140] calculate Verification ||Δ|| ∞ Check if ≤K+1 is true. If true, output 1 to represent Π. L Valid; otherwise, output 0.

[0141] In summary, the embodiments of this application provide a group management method with user-initiated linking and verifier condition revocation. Based on the assumptions of LWE and LWR hard problems, the embodiments of this application design a post-quantum-secure group signature scheme with user-initiated linking and verifier condition revocation. Security proofs and efficiency analyses show that this scheme is suitable for scenarios such as the Internet of Things, finance, and digital healthcare, and has good application prospects.

[0142] The signature scheme in this application conforms to the principles of impartial anonymity, traceability, and non-defamation, and can protect the privacy of legitimate users. In practical applications, it can also be used to prevent illegal user behaviors such as "multiple votes for one vote" and "double spending".

[0143] The group management method proposed in this application can receive signature information from any group member after publishing a group message, and verify the group message and signature information. Based on the first verification result and the group message, it is determined whether there is fraudulent activity in the signature process. If fraudulent activity is found, the group member corresponding to the signature information is identified and added to the revocation list to remove the group member from the group. The revocation process has no impact on other users who have not revoked, and avoids malicious revocation. It satisfies the requirements of anonymity, traceability, and non-defamation, and is applicable to scenarios such as the Internet of Things, finance, and digital healthcare. This solves the technical problems in related technologies, such as conflicting with the trend of decentralized privacy protection, difficulty in combining with technologies such as blockchain, high revocation costs, and difficulty in traceability.

[0144] Next, the group management device proposed according to the embodiments of this application is described with reference to the accompanying drawings.

[0145] Figure 4 This is a block diagram of a group management device according to an embodiment of this application.

[0146] like Figure 4 As shown, the management device 10 of the group includes: a first receiving module 100, a first verification module 200, and a first cancellation module 300.

[0147] Specifically, the first receiving module 100 is used to receive the signature information of any group member after the group message is published.

[0148] The first verification module 200 is used to verify the group message and signature information, obtain the first verification result, and combine the first verification result with the group message to determine whether there is fraudulent activity in the signature process.

[0149] The first revocation module 300 is used to identify the group member corresponding to the signature information in the event of fraudulent activity, and add the group member to the revocation list to remove the group member from the group.

[0150] Optionally, in one embodiment of this application, the group management device 10 further includes a determination module and an initialization module.

[0151] The determination module is used to determine the upper limit of the number of group members, the upper limit of the number of events, the hash function, and the binary conversion function of the group based on preset security parameters and calculation parameters.

[0152] The initialization module is used to initialize the group data and, in combination with the initial group data, security parameters, calculation parameters, maximum number of group members, maximum number of events, hash function, and binary conversion function, outputs a common parameter set to complete the group initialization.

[0153] Optionally, in one embodiment of this application, the group management device 10 further includes an output module, a second receiving module, and an update module.

[0154] The output module is used to output group key pairs using a trapdoor generation algorithm.

[0155] The second receiving module is used to receive locally generated user key pairs and group joining requests from users.

[0156] The update module is used to respond to a user's request to join a group by combining the group key pair and the user key pair, and to update the group information.

[0157] Optionally, in one embodiment of this application, the group management device 10 further includes: a third receiving module, a judging module, a second verification module, and a second cancellation module.

[0158] The third receiving module is used to receive data update requests from the group administrator.

[0159] The judgment module is used to determine whether the group's cancellation list is an empty set in response to a data update request.

[0160] The second verification module is used to verify whether the user ID of each group member in the group has completed the user counter accumulation when the cancellation list is empty, obtain the second verification result, and publish the updated group information based on the second verification result.

[0161] The second revocation module is used to find the corresponding user tuple in the group's registration list by using the key corresponding to the identity identifier of the group member in the revocation list as an index, and set the user tuple to zero in order to complete the revocation of the group member.

[0162] Optionally, in one embodiment of this application, the group management device 10 further includes: an encryption module, a calculation module, a generation module, and a first acquisition module.

[0163] The encryption module is used to encrypt the relevant group recovery threshold of any group of members to obtain an encrypted value.

[0164] The calculation module is used to calculate the hash value and pseudonym of any group of members using a hash function.

[0165] The generation module is used to generate non-interactive zero-knowledge proofs that can verify the membership of any group of members, using hash values, pseudonyms, and cryptographic values.

[0166] The first acquisition module is used to obtain the signature information of any group of members that meet the preset verifiable conditions using non-interactive zero-knowledge proofs.

[0167] Optionally, in one embodiment of this application, the group management device 10 further includes: a third verification module and a second acquisition module.

[0168] The third verification module is used to verify whether the non-interactive zero-knowledge proof meets the preset validity conditions.

[0169] The second acquisition module is used to obtain the signature information of any group of members that meet the preset verifiable conditions by using non-interactive zero-knowledge proof, provided that the preset validity conditions are met.

[0170] Optionally, in one embodiment of this application, the first verification module 200 includes: a first acquisition unit, a first verification unit, and a first determination unit.

[0171] The first acquisition unit is used to acquire the latest accumulated value of the group and use the latest accumulated value to parse the signature information to obtain the signature parameters.

[0172] The first verification unit is used to verify the signature parameters sequentially using multiple hash functions, and if the verification is successful, to determine whether the revocation list contains any group of members.

[0173] The first determining unit is used to determine that the signature information is invalid and terminate the current signing process if any group of members are included; otherwise, it determines whether there is fraudulent activity in the signing process based on the first verification result.

[0174] Optionally, in one embodiment of this application, the first cancellation module 300 includes: a second acquisition unit, a second verification unit, and a second determination unit.

[0175] The second acquisition unit is used to acquire any two signature information within the group.

[0176] The second verification unit is used to verify the legality of the two signature information respectively, and if both signature information is legal, it parses the two signature information respectively to obtain the pseudonym and associated group message corresponding to each signature information.

[0177] The second determining unit is used to determine whether fraudulent activity exists based on the pseudonym and group messages. It should be noted that the foregoing explanation of the group management method embodiment also applies to the group management device of this embodiment, and will not be repeated here.

[0178] The group management device proposed in this application can receive signature information from any group member after publishing a group message, and verify the group message and signature information. Based on the first verification result and the group message, it determines whether there is fraudulent activity in the signature process. If fraudulent activity is found, the group member corresponding to the signature information is identified, and the group member is added to the revocation list to remove the group member from the group. The revocation process has no impact on other users who have not revoked, and avoids malicious revocation. It satisfies the requirements of impartial anonymity, traceability, and non-defamation, and is applicable to scenarios such as the Internet of Things, finance, and digital healthcare. This solves the technical problems in related technologies, such as conflicting with the trend of decentralized privacy protection, difficulty in combining with technologies such as blockchain, high revocation costs, and difficulty in traceability.

[0179] Figure 5 A schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device may include:

[0180] The memory 501, the processor 502, and the computer program stored on the memory 501 and capable of running on the processor 502.

[0181] When processor 502 executes the program, it implements the group management method provided in the above embodiments.

[0182] Furthermore, electronic devices also include:

[0183] Communication interface 503 is used for communication between memory 501 and processor 502.

[0184] The memory 501 is used to store computer programs that can run on the processor 502.

[0185] The memory 501 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0186] If the memory 501, processor 502, and communication interface 503 are implemented independently, then the communication interface 503, memory 501, and processor 502 can be interconnected via a bus to complete communication between them. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, Figure 5 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0187] Optionally, in a specific implementation, if the memory 501, processor 502, and communication interface 503 are integrated on a single chip, then the memory 501, processor 502, and communication interface 503 can communicate with each other through an internal interface.

[0188] Processor 502 may be a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application.

[0189] This embodiment also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the group management method described above.

[0190] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the group management method provided in this embodiment of the invention.

[0191] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0192] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "N" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0193] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or N executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

[0194] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can be any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable media include: an electrical connection having one or more wires (electronic device), a portable computer disk drive (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Alternatively, the computer-readable medium may be paper or other suitable media on which the program can be printed, since the program can be obtained electronically by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in a computer memory.

[0195] It should be understood that the various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, the N steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0196] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0197] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0198] The storage medium mentioned above can be a read-only memory, a disk, or an optical disk, etc. Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions, and variations to the above embodiments within the scope of this application.

Claims

1. A method for managing groups, characterized in that, Includes the following steps: After posting a group message, receive signature information from any group member; The group message and the signature information are verified to obtain a first verification result. The first verification result and the group message of the group are combined to determine whether there is fraudulent activity in the signature process. If the fraudulent activity exists, the group member corresponding to the signature information is identified, and the group member is added to the revocation list to remove the group member from the group; Specifically, the upper limit of the number of group members, the upper limit of the number of events, the hash function, and the binary conversion function of the group are determined according to preset security parameters and calculation parameters; the group data is initialized, and a common parameter set is output by combining the initialized group data, the security parameters, the calculation parameters, the upper limit of the number of group members, the upper limit of the number of events, the hash function, and the binary conversion function to complete the initialization of the group; Before receiving the signature information of any group of members, the method further includes: encrypting the relevant group recovery threshold of the any group of members to obtain an encrypted value; calculating the hash value and pseudonym of the any group of members using a hash function; generating a non-interactive zero-knowledge proof for verifying the any group of members using the hash value, the pseudonym, and the encrypted value; and obtaining the signature information of the any group of members that meets the preset verifiable conditions using the non-interactive zero-knowledge proof. The step of determining whether fraudulent activity exists in the signature process by combining the first verification result and the group message of the group includes: obtaining any two signature information in the group; verifying the legality of the two signature information respectively, and if both signature information is legal, parsing the two signature information respectively to obtain the pseudonym and associated group message corresponding to each signature information; and determining whether fraudulent activity exists based on the pseudonym and the group message.

2. The method according to claim 1, characterized in that, After the initialization of the group is completed, the following is also included: Output group key pairs using a trapdoor generation algorithm; Receive locally generated user key pairs and group join requests from users; The system combines the group key pair and the user key pair to respond to the user's request to join the group and updates the group information.

3. The method according to claim 2, characterized in that, After updating the group information of the group, the following is also included: Receive data update requests from the group administrator; In response to the data update request, determine whether the group's undo list is an empty set; If the cancellation list is an empty set, then verify whether the user ID of each group member in the group has been incremented by the user counter to obtain a second verification result, and publish the updated group information based on the second verification result; If the revocation list is not empty, the key corresponding to the identity identifier of the group member to be revoked in the revocation list is used as the index to find the corresponding user tuple in the registration list of the group, and the user tuple is set to zero to complete the revocation of the group member.

4. The method according to claim 1, characterized in that, After generating a non-interactive zero-knowledge proof to verify the membership of any of the said groups, the process further includes: Verify whether the non-interactive zero-knowledge proof meets the preset validity conditions; If the preset validity condition is met, the signature information of any group of members that meets the preset verifiability condition is obtained using the non-interactive zero-knowledge proof.

5. The method according to claim 1, characterized in that, The verification of the group message and the signature information includes: Obtain the latest accumulated value of the group, and use the latest accumulated value to parse the signature information to obtain the signature parameters; The signature parameters are verified sequentially using multiple hash functions, and if the verification is successful, it is determined whether the revocation list contains any of the group members. If any of the aforementioned groups of members are included, the signature information is determined to be invalid, and the current signature process ends; otherwise, the signature process is determined to be fraudulent based on the first verification result.

6. A group management device, characterized in that, include: The first receiving module is used to receive the signature information of any group member after the group message is published; The first verification module is used to verify the group message and the signature information, obtain a first verification result, and combine the first verification result with the group message of the group to determine whether there is fraudulent activity in the signature process; The first revocation module is used to identify the group member corresponding to the signature information and add the group member to the revocation list in the event of the fraudulent activity, so as to delete the group member from the group. The determination module is used to determine the upper limit of the number of group members, the upper limit of the number of events, the hash function, and the binary conversion function of the group based on preset security parameters and calculation parameters; An initialization module is used to initialize group data and, in conjunction with the initialized group data, the security parameters, the calculation parameters, the upper limit of the number of group members, the upper limit of the number of events, the hash function, and the binary conversion function, output a common parameter set to complete the initialization of the group. The encryption module is used to encrypt the relevant group recovery threshold of any group of members to obtain an encrypted value; The calculation module is used to calculate the hash value and pseudonym of each group member using a hash function; A generation module is used to generate a non-interactive zero-knowledge proof for verifying membership in any group of members using the hash value, the pseudonym, and the encrypted value. The first acquisition module is used to obtain the signature information of any group of members that satisfy the preset verifiable conditions using the non-interactive zero-knowledge proof. The first revocation module includes: a second acquisition unit, used to acquire any two signature information within the group; a second verification unit, used to verify the legality of the two signature information respectively, and if both signature information are legal, to parse the two signature information respectively to obtain the pseudonym and associated group message corresponding to each signature information; and a second determination unit, used to determine whether the fraudulent activity exists based on the pseudonym and the group message.

7. An electronic device, characterized in that, include: A memory, a processor, and a computer program stored in the memory and executable on the processor, the processor executing the program to implement the group management method as described in any one of claims 1-5.

Images