A method and system for manageable privacy identity management against witch attacks

Abstract

The application belongs to the technical field of secure password application, and relates to a supervisable private identity management method and system resisting witch attack. The method comprises the following steps: a user applies for a certificate to a certificate authority CA; the user registers a pseudonym in an identity contract by using the obtained certificate; the user generates a non-witch proof or an identity attribute assertion proof of selectively disclosed identity information, and submits the proof to a DApp; the DApp performs witch resistance inspection or identity inspection to verify the identity attribute assertion proof submitted by the user, and after the inspection, the user can access the DApp; if it is found that the user or the pseudonym is malicious, a committee discloses or revokes information related to the identity and all related pseudonyms. The application supports a comprehensive supervisable governance mechanism and fine-grained witch attack resistance, simultaneously provides strong privacy protection capability, and has multiple excellent key characteristics such as decentralization, support for large-scale pseudonym tracking, high efficiency, support for selective linkage and the like.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of secure password application, and particularly relates to an anti-witch attack supervisable private identity management method and system. BACKGROUND

[0002] The cryptographic schemes involved in the application mainly include the following five kinds:

[0003] (1) Secret sharing: used for dividing a secret into several different fragments, and the secret can be restored only by more than a certain number of fragments. A commonly used secret sharing scheme is the Shamir scheme. When the number of people receiving the secret fragments is n, and it is required that no less than t people can restore the secret, it is also called (t, n)-Shamir secret sharing.

[0004] (2) Zero-knowledge proof (NIZK): used for proving that a set of data satisfies a certain condition without providing the specific value of the data, ensuring data privacy.

[0005] (3) Digital signature: used for authenticating that a certain data is given by a certain entity.

[0006] (4) Merkle tree: allows a data holder to make a commitment to a set of data and has the ability to prove the existence / absence of any given data in the set.

[0007] (5) Generalized Pedersen commitment: used for hiding the value of identity attributes into a commitment.

[0008] (6) Threshold public key encryption (TPKE): the encryption process is the same as traditional public key encryption, but decryption requires the participation of a certain threshold t of decrypt key holders. Specifically, each participant can use their own partial key to decrypt to obtain a "partial decryption" of the plaintext, but a complete ciphertext can be calculated based on a threshold number of partial decryptions.

[0009] Benefiting from the openness and independence of trusted third parties of the blockchain, decentralized applications (DApp) have made great progress in many fields. However, these characteristics also lead to limitations and even potential legal and regulatory risks when DApp uses access control mechanisms based on real user identities. A simple solution to implement identity-based access control is to attach a certificate issued by a certificate authority (CA) to the user's wallet to bind the user's address to their real identity. However, this solution has the risk of revealing user identity information. How to implement identity-based access control on the blockchain while protecting the privacy and security of users' identities is a major challenge.

[0010] Although the existing decentralized identity and pseudonym certificate-based scheme has strong privacy protection characteristics, it has three obvious limitations, namely insufficient support for regulatory governance (auditable, traceable, revocable), inability to resist witch attack and low running efficiency. SUMMARY

[0011] In order to break through the above three limitations, the present application proposes a witch attack-resistant and regulatable privacy identity management method and system.

[0012] The technical scheme adopted by the present application is as follows:

[0013] A witch attack-resistant and regulatable privacy identity management method, comprising the following steps:

[0014] The user applies for a certificate to the certificate authority CA;

[0015] The user registers a pseudonym in the identity contract by using the obtained certificate;

[0016] The user generates a non-witch proof or an identity attribute assertion proof of optional identity information disclosure, and submits it to the DApp;

[0017] The DApp performs witch attack-resistant inspection or identity inspection to verify the identity attribute assertion proof submitted by the user, and after the inspection is passed, the user can access the DApp;

[0018] If it is found that the user or the pseudonym is malicious, the committee discloses or revokes the information related to the identity and all related pseudonyms.

[0019] Further, the user applies for a certificate to the certificate authority CA, comprising:

[0020] 1) The user generates his own private key sk U ;

[0021] 2) The user generates his own trapdoor β;

[0022] 3) The user calculates the public key pk U and the trapdoor commitment B through the private key and the trapdoor;

[0023] 4) The user calculates the tracking string ψ t ;

[0024] 5) The user calculates the zero-knowledge proof π C and sends pk U , B, ψ t , π C to the CA;

[0025] 6) The CA verifies whether the identity information and the zero-knowledge proof of the user are correct;

[0026] 7) CA determines the user's to-be-authorized identity attribute {a j} j∈S Calculate the commitment value A;

[0027] 8) CA determines the validity period e of the certificate, generates the certificate Γ and signs it, and sends the signature σ to the user;

[0028] 9) The user verifies whether the signature is correct, and saves the certificate Γ.

[0029] Further, the user registers a pseudonym in the identity contract using the obtained certificate, including:

[0030] 1) The user determines the validity period e of the pseudonym t ≤e;

[0031] 2) The user binds the identity commitment A for the pseudonym t ;

[0032] 3) The user selects the upper and lower bounds m0, m1 of the nonce that can be used by himself;

[0033] 4) The user selects a nonce between m0 and m1;

[0034] 5) The user calculates the random number k;

[0035] 6) The user calculates the audit string ψ a ;

[0036] 7) The user calculates the zero-knowledge proof π P , and sends the data in 1) ~ 3) and 6) to the identity contract in the form of a block chain transaction T ξ ;

[0037] 8) The identity contract checks the validity of the upper and lower bounds and the proof, and records the sender ξ U of the transaction and stores the relevant data;

[0038] 9) The identity contract returns the registration result to the user, returns success if there is no failed check, otherwise returns failure;

[0039] 10) The user confirms the result and stores the relevant data.

[0040] Further, the DApp implements the anti-malicious attack by the following steps:

[0041] 1) The user calculates the maximum number of instances n that can be generated according to the limit function limit() of the application to the number of instances;

[0042] 2) The user randomly generates a nonce in the range of 0 ~ n-1 for the current access to the application;

[0043] 3) The user calculates the token of the current access

[0044] 4) The user calculates the zero-knowledge proof π S and sends his public key to the application π S ;

[0045] 5) The application obtains the audit string and attribute commitment from the user's pseudonym;

[0046] 6) The application verifies whether the user's identity information and zero-knowledge proof are correct;

[0047] 7) If the verification is passed, the application stores the token corresponding to the user's pseudonym, returns the result Res=1 to the user, representing that the verification is passed, otherwise returns Res=0, representing that the verification fails;

[0048] 8) The user stores his pseudonym, nonce, and the token of the current access.

[0049] Further, when the user accesses the DApp, the DApp is provided with a zero-knowledge proof to prove that the identity attribute bound to the commitment value A t satisfies the given requirements without revealing the value of the identity attribute; the zero-knowledge proof is as follows:

[0050]

[0051] wherein π D represents the generated zero-knowledge proof, a1, a2,..., a n represent the identity attribute of the user, A t represents the commitment value of the user's identity attribute, and the function f represents the condition required by the DApp for the identity attribute to satisfy.

[0052] Further, the committee initiates an audit on the user's pseudonym ξ U by using the following steps:

[0053] 1) The committee obtains the audit string ψ a corresponding to ξ U from the identity contract;

[0054] 2) Not less than t members in the committee respectively use their private keys sk j to decrypt ψ a to obtain the decrypted shares

[0055] 3) The not less than t members combine the decrypted shares to restore the complete audit string ψ a ;

[0056] 4) The committee calculates the public key pk of the CA selected during user registration. i Then, the corresponding CA is accessed to obtain the user's identity data, thereby revealing the identity information associated with the pseudonym.

[0057] Furthermore, the committee employs the following steps to verify the user's identity ID. U Initiate tracking:

[0058] 1) The committee retrieves the tracking string ψ of the corresponding user from the CA. t And each of the t members uses its own private key sk j Decrypting ψ t Obtain the decryption share

[0059] 2) The at least t members combine the decrypted shares to recover the complete tracing trapdoor β and the public key pk of the CA selected during user registration. i ;

[0060] 3) The committee calculates the range of users' nonces by tracing trapdoors;

[0061] 4) The committee calculates the first element C0 of the user's audit string using the nonce range;

[0062] 5) The committee screened out all the pseudonyms corresponding to the audit strings that met the requirements, all of which belonged to the users under investigation.

[0063] Furthermore, the committee employs the following steps to revoke the user's pseudonym ξ U With voucher Γ:

[0064] 1) Transfer the user's public key pk corresponding to the credential Γ. U Add to the undo tree τ r middle;

[0065] 2) Remove the root γ of the newly revoked tree r Submit to the identity contract to complete the update;

[0066] 3) No fewer than t committee members will use pseudonyms ξ in their identity contracts. U The status has been updated to "Revoked".

[0067] The anti-witch attack supervisable privacy identity management system comprises a committee module, a certificate authority module, an identity contract module, a DApp module and a user module; the user module applies for a certificate from the certificate authority module, and registers a pseudonym in the identity contract module by using the obtained certificate; the user module generates a non-witch proof or an identity attribute assertion proof of selectively disclosed identity information, and submits it to the DApp module; the DApp module performs an anti-witch check or an identity check to verify the identity attribute assertion proof submitted by the user module, and after the check passes, the user module can access the DApp module; if it is found that the user or the pseudonym is malicious, the committee module discloses or revokes the information related to the identity and all related pseudonyms.

[0068] The beneficial effects of the present application are as follows:

[0069] The present application supports comprehensive regulatory governance mechanisms (traceable, auditable, revocable) and fine-grained anti-witch attack, while providing strong privacy protection capabilities, and has the key features of decentralization (all identity management operations are completed by a committee containing multiple different entities), supporting large-scale pseudonym tracking, high efficiency (most tracking calculations can be executed locally on a single node), supporting selective linking (allowing users to selectively disclose the linkability of their pseudonyms without revealing identity-related information), and the like. BRIEF DESCRIPTION OF DRAWINGS

[0070] Figure 1 is a system architecture diagram of the present application.

[0071] Figure 2 The certificate generation process is shown.

[0072] Figure 3 The pseudonym registration process is shown.

[0073] Figure 4 The application anti-witch attack process is shown.

[0074] Figure 5 The audit, tracking and revocation process is shown, wherein DB u a The database for storing user information for the CA. DETAILED DESCRIPTION

[0075] In order to make the above features and advantages of the present application more obvious and easy to understand, the following embodiments are described in detail below, together with the accompanying drawings.

[0076] 1. System model

[0077] To implement the present application, a system composed of a series of off-chain programs and on-chain contracts needs to be constructed, and the system architecture is as shown in Figure 1 ​

[0078] (1) Committee: composed of multiple different entities responsible for system management and identity regulatory governance. The committee works in a threshold manner, i.e., all operations require the cooperation of at least t entities.

[0079] (2) Certificate Authority (CA): an authorized agency responsible for verifying and storing user identity attributes and assisting the committee in regulatory governance. The system supports multiple CAs, allowing different CAs to verify identity attributes, and each CA can verify different identity attributes.

[0080] (3) Identity Contract (IC): a system contract for verifying, storing, and managing user pseudonyms. Specifically, users can invoke the identity contract to register pseudonyms and bind them to specific identity attributes. In addition, the identity contract provides identity checks, anti-mitigation checks, and regulatory governance interfaces.

[0081] (4) DApp: DApp, or Decentralized Application, is an application program with a series of smart contracts deployed on the blockchain as the backend. It can call the identity contract to perform identity checks and anti-mitigation checks.

[0082] (5) User: uses a pseudonym (such as an on-chain account address) to interact with DApps, proving that their access complies with DApp access control, such as identity proof and non-mitigation address proof. The system assumes that users may act maliciously, i.e., take arbitrary actions to gain benefits.

[0083] 2. System setup and workflow

[0084] 2.1) Threshold encryption setup

[0085] When the system starts running, the committee runs a distributed key generation protocol (an existing distributed key generation protocol can be used) to obtain (pk, sk), where pk is the public key and sk is the private key. sk remains private, but each committee member obtains a share of sk through a (t, n)-Shamir secret sharing protocol, i.e., only t or more members can cooperate to obtain the complete sk. The committee publishes pk to the identity contract. In addition, each CA in the system has a number i and a key (pk i ,sk i ), where pk i = sk i G. G is a random base point on an elliptic curve.

[0086] 2.2) Zero-knowledge proof setup

[0087] The system can be implemented by any existing general zero-knowledge proof scheme. In particular, if a zk-SNARK type scheme is used, a set of data called a common reference string (CRS) needs to be generated at the beginning of the operation, and the committee members in the system can achieve this through any existing multi-party secure computation protocol.

[0088] 2.3) Elliptic curve base point setting

[0089] Some cryptographic schemes in the present application involve elliptic curve operations and require a random base point G on the elliptic curve. For example, a basic generalized Pedersen commitment calculation scheme is as follows: for n attribute values v1, v2,..., v n and n+1 base points G, G1, G2,..., Gn+1, select a random number r, and the commitment value is n

[0090] Therefore, the present application selects multiple random base points on the elliptic curve by the following method: first, the committee runs a multi-party random number generation protocol (which can use an existing multi-party random number generation protocol) to obtain a random number seed, then generates the same number of random numbers as the required base points from the random number seed, and maps them to points on the elliptic curve through a mapping algorithm, and publishes these base points in the identity contract, and users can generate commitments to their identity attributes accordingly.

[0091] 2.4) System workflow

[0092] The overall workflow of the system is as follows:

[0093] (1) The user applies for a certificate to the CA in the CA list;

[0094] (2) The user can register a pseudonym in the identity contract using the obtained certificate;

[0095] (3) If the DApp has an anti-malicious instance of a custom access control policy, the user generates a non-malicious proof or an identity attribute assertion proof that discloses identity information, and submits it to the DApp;

[0096] (4) The DApp performs an anti-malicious check or an identity check to verify the proof submitted by the user, and after the check is passed, the user can access the DApp;

[0097] (5) If the user or pseudonym is found to be malicious, the committee will disclose or revoke the identity-related information and all related pseudonyms.

[0098] 3. System operation mode

[0099] 3.1) Certificate generation

[0100] ​User U first generates two random numbers sk U and β, the former as user private key, the latter as tracking trapdoor. Then the user sends pk U = sk U G and B = βG to CA, where pk U represents user public key, B represents user's commitment to tracking trapdoor, and the user can prove B corresponds to correct tracking trapdoor by zero-knowledge proof to CA. To achieve traceability, the user must provide CA with TPKE ciphertext of tracking trapdoor as tracking string, and encrypt tracking trapdoor β together with CA's public key pk i :

[0101] ψ t ← Enc(pk, Encode(α), pk i ) = (kG, (k·pk).x·Encode(β), (k·pk).y·pk i )

[0102] where ψ t is the user's last calculated tracking string, Enc is the encryption algorithm designed in this step (i.e. the content on the right side of the equation above), ← means assigning the value calculated on the right side to the variable on the left side, k is a random number,.x and.y represent the horizontal and vertical coordinates of a point on the elliptic curve respectively, and Encode function encodes a numerical value into a point on the elliptic curve. Further, to ensure that the encrypted trapdoor submitted by the user is correct, the user also needs to submit a set of zero-knowledge proof data to demonstrate that the user indeed has β, k and the submitted ciphertext is indeed calculated correctly from the two. The zero-knowledge proof data is:

[0103] π C ← NIZK{(β, k): B = βG

[0104] ∧ ψ t = Enc(pk, Encode(β), pk i )}

[0105] Finally, the user submits (pk U , B, ψ t , π C ) and the document containing the identity attributes to be authorized {a j} j∈S to CA, and CA issues the user a certificate Γ = (pk U || B || A || e, σ) after verification, where A = ∑ j∈s a j G j is the commitment value of user's identity attributes, e is the validity period of the certificate, and σ is the signature of CA on the content of the certificate.

[0106] Figure 2 The credential generation process is shown, which includes the following steps:

[0107] 1) The user generates his own private key sk U ;

[0108] 2) The user generates his own trapdoor β

[0109] 3) The user calculates the public key pk U and the trapdoor commitment B through the private key and the trapdoor;

[0110] 4) The user calculates the tracking string ψ t ;

[0111] 5) The user calculates the zero-knowledge proof π C and sends the data pk U , B, ψ t , π C in 3) ~ 5) to the CA;

[0112] 6) The CA verifies whether the identity information and the zero-knowledge proof of the user are correct;

[0113] 7) The CA calculates the commitment value A through the identity attribute to be authorized of the user {a j} j∈S ;

[0114] 8) The CA determines the validity period e of the credential, generates the credential Γ and signs it to obtain the signature σ, and sends it to the user;

[0115] 9) The user verifies whether the signature is correct, and saves the credential Γ.

[0116] Figure 2 In the formula, Zp is a set of all natural numbers less than a prime number p, and CRS is a public reference string (the same below) needed for generating a zero-knowledge proof.

[0117] 3.2) Pseudonym registration

[0118] The user can register a pseudonym (i.e. a blockchain address) on the identity contract by using the credential. The user must set a validity period e t ≤ e for the pseudonym when registering the pseudonym, and bind an identity commitment A t = A + r t G for each registered pseudonym, where r t is a secret random number different for each registered pseudonym. This method can calculate a generalized Pedersen commitment that can perfectly hide the identity attribute.

[0119] To give the real identity information when necessary, the user needs to provide an audit string for each pseudonym, which is a TPKE encryption of the user public key pk U and the issuer public key pk i , where the issuer is the CA that issued the credential to the user. To prevent an attacker from reusing the string for other pseudonyms, the encoding of the audit string contains its corresponding pseudonym, making it valid only for the corresponding pseudonym ξ U :

[0120] ψ a ← Enc(pk, pk U , (pk i + ξ U G)) = (kG, (k pk).x pk U , (k pk).y (pk i + ξ U G)

[0121] Further, to ensure that the pseudonym is traceable, the system restricts the way the random number k is generated in the above formula, requiring that its calculation must include the tracking trapdoor corresponding to the credential and a nonce value within a certain range w, i.e. k = Hash(β || nonce).

[0122] The user also needs to prove the correctness of the above information through zero-knowledge proof, and prove that he is the owner of the credential. Specifically, the user initiates a transaction to the identity contract in the system, submits the above data, and the identity contract verifies the zero-knowledge proof and does other validity checks. Once the verification is passed, the registration is accepted, and the user's pseudonym validity period, commitment value and audit string will be recorded in the identity contract. In addition, the user also needs to prove that the credential used has not been revoked, and that the issuer is a CA member of the system. For this purpose, the system committee maintains two Merkle trees, namely the CA tree τ c and the revoked tree τ r , the former is used to store the public keys of all CAs, and the latter stores the master public keys of all revoked credentials. When adding a new CA or revoking a credential, the committee will update the two trees and record the new tree root hash value on the identity contract.

[0123] In summary, the zero-knowledge proof submitted by the user is in the form of:

[0124] π R ← NIZK{(sk U , β, Γ, r t , nonce, π R , π C ) : e t ≤ Γ.e

[0125] ∧ k = Hash(β || nonce) ∧ m0≤ nonce≤ m1

[0126] ∧ψ a =Enc(pk,pk U ,(pj i +ξ U G))

[0127] ∧A t =A+r t G

[0128] ∧sk U G = Γ.pk U

[0129] ∧βG=Γ.B∧1=SigVerify(pk i ,Γ.pk U ||Γ.B||Γ.A||Γ.e,Γ.σ)

[0130] ∧1=InVerify(π C ,pk i TreeRoot(τ c ))

[0131] ∧1=NotInVerify(π R ,pk U TreeRoot(τ r ))}

[0132] A user submits a transaction, which will (e t A t ,ψ a ) and (π P (m0, m1) are uploaded to the identity contract. After the contract verifies and approves the pseudonym registration, it is recorded (e t A t ,ψ a ).

[0133] Figure 3 The pseudonym registration process is shown, including the following steps:

[0134] 1) The user determines the validity period of the pseudonym. t ≤e;

[0135] 2) User binds pseudonym to identity commitment A t ;

[0136] 3) Users select their own usable upper and lower limits for nonce, m0 and m1;

[0137] 4) The user selects a nonce between m0 and m1;

[0138] 5) The user calculates a random number k;

[0139] 6) User computes audit string ψ a ;

[0140] 7) User computes zero-knowledge proof π P and sends data in 1)~3) and 6) to identity contract in the form of a blockchain transaction T ξ ;

[0141] 8) Identity contract checks upper and lower bounds and validity of the proof, and records the sender ξ U of the transaction (i.e. the user pseudonym), stores relevant data;

[0142] 9) Identity contract returns registration result to the user, returns success (1) if there is no failed check, otherwise returns failure (0);

[0143] 10) User confirms the result and stores relevant data.

[0144] 3.3) Application Anti-magic Attack

[0145] The system provides an n-time access token generation scheme, which inputs the credential private key and anti-magic attack instance ID as input, and can output up to n different tokens:

[0146]

[0147] Where sk u is the private key of the credential, ζ is the anti-magic attack instance ID, and the upper limit of nonce can be determined by each application according to the number of user attributes and implemented in a specific limit function limit().

[0148] When implementing anti-magic attack, the application first initializes an anti-magic attack instance with instance ID ζ and nonce limit. The user accessing the application should provide an access token generated with this instance ID for each pseudonym used. The user also needs to generate a zero-knowledge proof based on the audit string ψ a of the used pseudonym and Pedersen commitment A t (i.e. non-magic proof in step (3) of the system flow in the previous text) to demonstrate the correctness of the provided token (in order to improve efficiency, the application can hardcode its nonce limit scheme into a dedicated zero-knowledge proof circuit):

[0149] π S ←NIZK{(sk U ,nonce,k,{a i},r t )∶sk U G=pk U

[0150] ∧ψ a = Enc(pk, pk U , (pk i + ξ U G))

[0151]

[0152] ∧0≤ nonce < limit(pk U , {a i})

[0153] ∧A t = A + r t G}

[0154] Finally, the application checks whether the access token is duplicated and verifies the proof.

[0155] Figure 4 The flow of the application against the Sybil attack is shown, which includes the following steps:

[0156] 1) The user calculates the maximum number of instances n that can be generated according to the limit function limit() of the application (i.e. DApp);

[0157] 2) The user randomly generates a nonce in the range of 0 to n-1 for the current access of the application;

[0158] 3) The user calculates the token for the current access

[0159] 4) The user calculates the zero-knowledge proof π S , and sends the public key of the user and the data in 3) to 4) π S to the application;

[0160] 5) The application obtains the audit string and attribute commitment through the pseudonym of the user;

[0161] 6) The application verifies whether the identity information and the zero-knowledge proof of the user are correct;

[0162] 7) If the verification is passed, the application corresponds the token to the pseudonym of the user and stores it, and returns the result Res=1 (representing that the verification is passed) to the user, otherwise returns Res=0 (representing that the verification fails);

[0163] 8) The user stores the pseudonym, nonce and token of the current access.

[0164] 3.4) User accesses DApp

[0165] When a user accesses a DApp, the user can need to prove to the application that his identity attributes meet certain requirements (e.g. being at least 18 years old) in order to meet the access control requirements. To this end, the user can provide a zero-knowledge proof (i.e. the identity attribute attestation proof in step (3) of the foregoing system flow) to the DApp to prove that his identity attributes bound to the commitment value A t meet the given requirements (denoted by function f) without revealing the values of these identity attributes. The generated zero-knowledge proof is as follows:

[0166]

[0167] where π D represents the generated zero-knowledge proof, a1,a2,...,a n represent the identity attributes of the user, A t represents the commitment value of the identity attributes of the user, and function f represents the condition that the DApp requires the identity attributes to meet (which can be any computable function).

[0168] 3.5) Supervision governance mechanism

[0169] Audit: In the pseudonym registration process, the user needs to submit an audit string ψ a to the identity contract, which is a TPKE encryption of the user public key pk U and the issuer public key pk i . If a pseudonym has malicious behavior, its identity-related information can be disclosed by a certain number (not less than t) of committee members in the following way: the committee first obtains the corresponding ψ a from the identity contract, and then decrypts ψ a together with not less than t members to recover pk U and pk i , and then queries the CA identified by pk U through pk i to reveal the identity information associated with the pseudonym.

[0170] Tracking: In order to track a user, the supervisory authority can require the CA that issued the corresponding credential to submit a tracking string ψ t to the committee, and then not less than t committee members can cooperate to decrypt ψ t to recover the tracking trapdoor β. After that, the supervisory party can calculate all the nonces within a certain range and their corresponding pseudonyms generated with the random number k on its own. Thus, among the registered pseudonyms, all the pseudonyms whose first element of the audit string is kG belong to the user being investigated. Since honest users account for the majority of the committee members, it is not feasible to track honest users.

[0171] Revocation: When at least t members of the committee agree, a credential or pseudonym can be revoked in the following way: the committee first adds the credential's public key (i.e. pk U ) to the revocation tree, then submits the new root of the revocation tree to the identity contract with signatures of at least t members, after which the pseudonym registration proof using this credential will fail verification; when revoking a pseudonym, at least t members of the committee update the status of the pseudonym to "revoked" in the identity contract. Pseudonyms with status "revoked" are no longer valid.

[0172] Figure 5 The audit, trace and revocation processes are shown, where DB u a stores user information for the CA.

[0173] Audit process: The committee initiates an audit on a user pseudonym ξ U , including the following steps:

[0174] 1) The committee obtains the corresponding audit string ψ U from the identity contract for ξ a ;

[0175] 2) At least t members of the committee decrypt ψ j using their own private keys sk a , respectively, to obtain the decrypted shares

[0176] 3) The members combine the decrypted shares to recover the complete audit string ψ a (the first part is pk U , and the second part is denoted as M2);

[0177] 4) The committee calculates the public key pk i of the CA selected by the user at registration, and then accesses the corresponding CA to obtain the user's identity data, thereby revealing the identity information associated with the pseudonym.

[0178] Trace process: The committee initiates a trace on a user identity ID U , including the following steps:

[0179] 1) The committee queries the corresponding CA for the trace string ψ t for the user, and at least t members decrypt ψ j using their own private keys sk t , respectively, to obtain the decrypted shares

[0180] 2) The members combine the decrypted shares to recover the complete trace trapdoor β and the public key pk i of the CA selected by the user at registration.

[0181] 3) The committee calculates the range of users' nonces by tracing trapdoors;

[0182] 4) The committee calculates the first element C0 of the user's audit string using the nonce range;

[0183] 5) The committee screened out all the pseudonyms corresponding to the audit strings that met the requirements, and these pseudonyms all belonged to the users being investigated.

[0184] Revocation Process: The committee revokes the user's pseudonym. U With the voucher, the following steps are included:

[0185] 1) Transfer the user's public key pk corresponding to the credential Γ. U Add to the undo tree τ r middle;

[0186] 2) Remove the root γ of the newly revoked tree r Submit to the identity contract to complete the update;

[0187] 3) No fewer than t committee members will use pseudonyms ξ in their identity contracts. U The status has been updated to "Revoked".

[0188] One embodiment of the present invention assumes an application scenario where an organization wants to limit the number of NFTs a user can receive based on their identity attributes (e.g., the number of followers on a specific social media platform). Simultaneously, to protect privacy, it is necessary to hide the recipient's identity information, the number of NFTs received by each user, and the association information between recipients. Furthermore, to enhance security, if a user violates the rules (e.g., illegally trading NFTs), all NFTs received by that user should be identified and confiscated.

[0189] A Certificate Authority (CA) verifies the number of a user's social media followers and issues only one credential to each social media user. The CA instantiates an anti-Syllabic instance with the id ζ and a limit function 'limit()'. 'limit()' takes the user's identity attributes as input and returns 2 if the user has more than 100 social media followers, otherwise it returns 1. To receive an NFT, the user must first verify their social media follower count with the CA and request a credential (skipping this step if a request has already been made). Then, the user registers a pseudonym using the obtained credential and uses these pseudonyms to request NFTs. Furthermore, the user must generate an access token for each visit using the methods described in the "Application Anti-Syllabic Attack" section. The NFT application can only issue NFTs to previously unseen access tokens. Since the number of different access tokens that a user can generate will not exceed the value specified by limit(), i.e. a user with more than 100 social platform followers can generate at most two different access tokens, while other users can only generate one. This ensures that users with more than 100 fans can receive at most two NFTs, while other users can receive at most one. If the NFT holder violates the rules, the committee can discover her / his identity by reviewing, then find all the pseudonyms associated by tracking, and then find all the NFTs she / he holds, and confiscate these NFTs. This requires the cooperation of no less than t committee members, so it is done in a decentralized manner.

[0190] The above implementation has a privacy protection function. Since the nonce used by the receiver to generate the access token is not exposed, it is impossible to infer the upper limit of the receiver's NFT reception, and thus infer the identity attribute. It also improves security, because the relevant organization can not only freeze NFTs related to malicious behavior, but also discover the identity of malicious users and freeze all NFTs under their names.

[0191] Another embodiment of the present application provides a regulatable privacy identity management system resistant to witch attack, comprising a committee module, a certificate authority module, an identity contract module, a DApp module, and a user module; the user module applies for a certificate from the certificate authority module, and registers a pseudonym in the identity contract module using the obtained certificate; the user module generates a non-witch proof or an identity attribute assertion proof that optionally discloses identity information, and submits it to the DApp module; the DApp module performs witch resistance check or identity check to verify the identity attribute assertion proof submitted by the user module, and after the check passes, the user module can access the DApp module; if it is found that the user or the pseudonym is malicious, the committee module discloses or revokes information related to the identity and all related pseudonyms.

[0192] The division of the above modules is only an example, and in actual application, the above functions can be distributed to different functional modules to complete all or part of the functions described in the foregoing method. The specific working process of each module can refer to the corresponding process in the foregoing method embodiment, and will not be described here.

[0193] Another embodiment of the present application provides a computer device (computer, server, smart phone, etc.), which includes a memory and a processor, the memory stores a computer program, the computer program is configured to be executed by the processor, and the computer program includes instructions for executing each step in the method of the present application.

[0194] Another embodiment of the present application provides a computer readable storage medium (such as ROM / RAM, magnetic disk, optical disk) storing a computer program, which, when executed by a computer, implements each step of the method of the present application.

[0195] The above disclosed embodiments of the present application are intended to help understand the content of the present application and to implement the same, and those skilled in the art can understand that various replacements, changes and modifications are possible without departing from the spirit and scope of the present application. The present application should not be limited to the disclosed embodiments of the present application, and the scope of protection of the present application is defined by the scope of the claims.

Claims

1. A method of manageable privacy identity management against sorcery attack, characterized by, The method comprises the following steps: The user applies for a certificate to a certificate authority CA; The user registers a pseudonym in an identity contract using the obtained certificate; The user generates a non-malicious proof or an identity attribute assertion proof that optionally discloses identity information, and submits it to a DApp; the DApp performs an anti-malicious check or an identity check to verify the identity attribute assertion proof submitted by the user, and after the check passes, the user can access the DApp; If it is found that the user or the pseudonym is malicious, the committee discloses or revokes the information related to the identity and all related pseudonyms; The DApp implements anti-malicious attacks by the following steps: 1) The user calculates the maximum number of instances n that can be generated according to the limit function limit() of the application to the number of instances; 2) The user randomly generates a nonce in the range of 0 to n-1 for the current access to the application; 3) The user calculates the token for the current access 4) User computes zero-knowledge proof π S and sends his public key with π S to the application; 5) The application obtains the audit string and attribute commitment through the pseudonym of the user; 6) The application verifies whether the identity information and the zero-knowledge proof of the user are correct; 7) If the verification is passed, the application will return the token corresponding to the pseudonym of the user, and store it, returning the result Res = 1 to the user, representing that the verification is passed, or else returning Res = 0, representing that the verification is failed; 8) The user stores the pseudonym, nonce and token of this time.

2. The method of claim 1, wherein, The user applies for a certificate to a certificate authority CA, comprising: 1) The user generates his own private key sk u ; 2) The user generates his own trapdoor β; 3) The user computes the public key pk via the private key and the trapdoor U and the trapdoor commitment B; 4) User computes tracking string ψ t ; 5) User computes zero-knowledge proof π C and sends pk U , B, ψ t , π C to CA; 6) The CA verifies whether the identity information and the zero-knowledge proof of the user are correct; 7) CA passes the user's to-be-authorized identity attribute {a j} j∈S Compute commitment value A; 8) The CA determines the validity period e of the certificate, generates the certificate Γ and signs it, and sends the signature σ to the user; 9) The user verifies whether the signature is correct, and saves the certificate Γ.

3. The method of claim 1, wherein, The user registers a pseudonym in an identity contract using the obtained certificate, comprising: 1) The user determines the validity period e of the pseudonym t ≤ e; 2) the user binds the identity commitment A to a pseudonym t ; 3) The user selects the upper and lower limits m0, m1 of the nonce that he can use; 4) The user selects a nonce between m0 and m1; 5) The user calculates a random number k; 6) user computes audit string ψ a ; 7) The user computes the zero-knowledge proof π P and sends the data in 1) - 3) and 6) to the identity contract in the form of a blockchain transaction T ξ . 8) Identity contract checks upper and lower bounds and validity of attestation, and records sender ξ of transaction U , stores relevant data; 9) The identity contract returns the registration result to the user, and returns success if there is no failed check, otherwise returns failure; 10) The user confirms the result and stores the related data.

4. The method of claim 1, wherein, When a user accesses a DApp, they provide a zero-knowledge proof to the DApp to demonstrate their binding to the commitment value A. t The identity attributes satisfy the given requirements without revealing their values; the zero-knowledge proof is as follows: wherein, π D represents the generated zero-knowledge proof, a1, a2,..., a n represents the identity attribute of the user, A t represents the commitment value of the identity attribute of the user, and the function f represents the condition required by the DApp to be met by the identity attribute.

5. The method of claim 1, wherein, The committee adopts the following steps to pseudonymize the user's identity ξ U Initiate an audit: 1) committee gets ξ from identity contract U corresponding audit string ψ a ; 2) no less than t members of the committee each use their own private key sk j decrypt ψ a to obtain the decrypted share 3) the not less than t members combine the decrypted shares to recover the full audit string ψ a ; 4) The committee computes the public key pk of the CA selected by the user at registration i and then accesses the corresponding CA to obtain the user's identity data, thus revealing the identity information associated with the pseudonym.

6. The method of claim 1, wherein, The committee employs the following steps to authenticate a user identity ID U Initiate tracking: 1) The committee queries the CA for the tracing string ψ corresponding to the user t and each of the at least t members decrypts ψ using their own private key sk j t and obtains the decrypted share s ​ 2) the not less than t members combine the decryption shares to recover the full tracking trapdoor β and the public key pk of the CA chosen by the user at registration i ; 3) The committee calculates the nonce range of the user by tracking the trapdoor; 4) The committee calculates the first element C0 of the audit string of the user by the nonce range; 5) The committee filters out all pseudonyms corresponding to the audit strings that meet the requirements, which belong to the user being investigated.

7. The method of claim 1, wherein, The committee takes the following steps to revoke the pseudonym ξ of the user U with the credential Γ: 1) the user public key pk corresponding to the credential Γ U is added to the revocation tree τ r ; 2) Set the root of the new revocation tree γ r The identity contract is committed to the blockchain to complete the update. 3) At least t committee members update the status of the identity contract for pseudonym ξ to "revoked". U "revoked".

8. A governable privacy identity management system against sorcery attacks, characterized in that, The system comprises a committee module, a certificate authority module, an identity contract module, a DApp module and a user module; the user module applies for a certificate to the certificate authority module, and registers a pseudonym in the identity contract module using the obtained certificate; the user module generates a non-malicious proof or an identity attribute assertion proof that optionally discloses identity information, and submits it to the DApp module; The DApp module performs an anti-malicious check or an identity check to verify the identity attribute assertion proof submitted by the user module, and after the check passes, the user module can access the DApp module; if it is found that the user or the pseudonym is malicious, the committee module discloses or revokes the information related to the identity and all related pseudonyms; The DApp module implements anti-malicious attacks by the following steps: 1) The user calculates the maximum number of instances n that can be generated according to the limit function limit() of the application to the number of instances; 2) The user randomly generates a nonce in the range of 0 to n-1 for the current access to the application; 3) The user calculates the token for the current access 4) The user computes the zero-knowledge proof π S and sends his public key to the application π S along with 5) The application obtains the audit string and attribute commitment through the pseudonym of the user; 6) The application verifies whether the identity information and zero-knowledge proof of the user are correct; 7) If the verification is passed, the application will return the token corresponding to the pseudonym of the user, and store it, returning the result Res = 1 to the user, representing that the verification is passed, or else returning Res = 0, representing that the verification is failed; 8) The user stores the pseudonym, nonce and token of this time.

9. A computer device, comprising: A computer program product, comprising a memory storing a computer program configured to be executed by a processor, the computer program comprising instructions for performing the method of any one of claims 1-7. A computer program product, comprising a memory storing a computer program configured to be executed by a processor, the computer program comprising instructions for performing the method of any one of claims 1-7.

Images