Method, device, terminal equipment and readable storage medium for protecting identity privacy

Abstract

The application belongs to the technical field of blockchains, and particularly relates to a method and device for protecting identity privacy, a terminal device and a readable storage medium. In the method, a first proof of a supervision transaction voucher provided by a user node to a transaction node is generated based on a first supervision node identifier code issued by a supervision node and a target factor. Since the target factor is one of M first factors and the M first factors are all different, the same user can generate a plurality of different proofs including the first proof through the first supervision node identifier code and a plurality of first factors in multiple transactions. In this way, the plurality of different proofs can supervise the legality of the same transaction voucher. In this way, multiple transactions are not linked together. Even after multiple transactions, if a user exposes all attribute parameters except an account address, a third party cannot know whether the attribute parameters are derived from the same user, thereby protecting the identity privacy of the user.

Description

Technical Field

[0001] The present application relates to the field of blockchain, and in particular to a method, apparatus, terminal device, and readable storage medium for protecting identity privacy. Background Art

[0002] In order to prevent abnormal transactions, existing blockchain-based transaction methods monitor the legality of transactions through regulatory nodes.

[0003] However, existing regulatory methods often lead to the leakage of user node identity privacy, posing a huge security risk. Summary of the Invention

[0004] The embodiments of the present application provide a method, apparatus, terminal device, and storage medium for protecting identity privacy, which can protect the user's identity privacy while supervising the legitimacy of transactions.

[0005] In a first aspect, a method for protecting identity privacy is provided, which is applied to a supervisory node and includes:

[0006] Receiving a transaction credential, a first supervisory node identification code, and M first factors sent by the organization node, where the first supervisory identification code is used to identify the identity of the user node in the supervisory node, and the M first factors are different;

[0007] Generate a first certificate based on the first supervisory node identification code and a target factor, where the target factor is one of the M first factors;

[0008] A first signature message and the first certificate are sent to a transaction node, so that the transaction node verifies whether the transaction voucher is legitimate based on the first certificate, wherein the first signature message is obtained by signing a message based on the transaction voucher and at least one attribute parameter among multiple attribute parameters other than the attribute parameter used to represent the account address of the user node, wherein the multiple attribute parameters are used to represent different attributes of the user.

[0009] In the embodiment of the application, the first proof of the regulatory transaction certificate provided by the user node to the transaction node when the transaction is based on the first regulatory node identifier and the target factor. Since the target factor is one of the M first factors, and the M first factors are all different, the same user can generate multiple different proofs including the first proof through the first regulatory node identifier and multiple first factors when transacting multiple times. In this way, multiple different proofs can regulate the legality of the same transaction certificate. The same user can send multiple transactions using multiple different proofs, so multiple transactions cannot be linked together. Even after multiple transactions, if the user exposes all attribute parameters except the account address, a third party cannot know whether these attribute parameters come from the same user, thus protecting the user's identity privacy.

[0010] In one embodiment, the method further comprises:

[0011] storing the target factor in a first list;

[0012] if the M first factors are included in the first list, sending an update message to the regulatory node to make the regulatory node update the M first factors;

[0013] receiving the updated multiple first factors sent by the regulatory node through the organization node.

[0014] In the embodiment of the application, since the M first factors are included in the first list, the user node has used up the M first factors that can generate different proofs when transacting with the same transaction certificate. Therefore, an update message is sent to the regulatory node to make the regulatory node update the M first factors. The user generates different first proofs based on the updated multiple first factors. In this way, the same user can transact with different first proofs when transacting multiple times, thus protecting the user's identity privacy.

[0015] In one embodiment, the first proof is generated based on the first regulatory node identifier and the target factor, comprising:

[0016] The first proof is generated based on the first regulatory node identifier and the target factor according to the following formula:

[0017]

[0018] wherein, the first proof is represented by the first proof, the target factor is represented by r, and r represents the first regulatory node generation code.

[0019] In a second aspect, a method for protecting identity privacy is provided, applied to a regulatory node, comprising:

[0020] receiving a first organization node identifier sent by an organization node, the first organization node identifier being used to identify an identity of a user node in the organization node;

[0021] generating a first supervision node identifier and M first factors based on the first organization node identifier, the first supervision node identifier being used to identify the identity of the user node in the supervision node, the M first factors being different;

[0022] sending the first supervision node identifier and the M first factors to the organization node, so that the organization node determines a transaction credential of the user node based on the first supervision node identifier, and so that the user node generates a first proof based on the first supervision node identifier and a target factor when using the transaction credential to conduct a transaction, the target factor being one of the M first factors, the first proof being used to supervise the legality of the transaction credential.

[0023] The beneficial effects of the embodiments of the present application can be referred to the related description of the first aspect, which will not be repeated here.

[0024] In one embodiment, the method further comprises:

[0025] receiving an update message sent by the user node;

[0026] updating the M first factors according to the update message;

[0027] sending the updated plurality of first factors to the user node through the organization node.

[0028] In the embodiments of the present application, the supervision node can update the M first factors according to the update message, and the user node generates different first proofs based on the updated plurality of first factors, so that the same user can use different first proofs to conduct transactions when conducting multiple transactions, thereby protecting the identity privacy of the user.

[0029] In one embodiment, the method further comprises:

[0030] receiving a verification request sent by a transaction node;

[0031] determining a plurality of proofs corresponding to each supervision node identifier in the N supervision node identifiers based on each supervision node identifier and the plurality of first factors corresponding to the each supervision node identifier in a second list, the second list storing supervision node identifiers corresponding to at least one transaction credential that has been revoked, the first supervision node identifier being one of the N supervision node identifiers;

[0032] A third list is sent to the transaction node, so that the transaction node verifies whether the transaction certificate of the user node is legitimate based on the third list, wherein the third list includes the multiple certificates.

[0033] In one embodiment, a fourth list is configured in the supervisory node, the fourth list including at least one supervisory node identification code and at least one organization node identification code, the at least one supervisory node identification code and the at least one organization node identification code being in one-to-one correspondence, and the method further includes:

[0034] receiving revocation evidence and the first organization node identification code;

[0035] If the revocation evidence passes verification, determining the first supervisory node identification code corresponding to the first organization node identification code in the fourth list;

[0036] The first supervisory node identification code is stored in the second list.

[0037] In one embodiment, a fourth list is configured in the supervisory node, the fourth list including at least one supervisory node identification code and at least one organization node identification code, the at least one supervisory node identification code and the at least one organization node identification code being in one-to-one correspondence, and the method further includes:

[0038] receiving a revocation evidence, the first proof, and the target factor;

[0039] If the revocation evidence passes verification, determining a second proof based on the target factor and the at least one supervisory node identification code in the fourth list;

[0040] If the first certificate is the same as the second certificate, the supervisory node identification code corresponding to the second certificate is stored in the second list.

[0041] Thirdly, a method for protecting identity privacy is provided, which is applied to transaction nodes and includes:

[0042] receiving a first certificate and first signature information sent by a user node, where the first certificate is obtained based on a first supervisory node identification code and a target factor, where the first supervisory node identification code is used to identify the identity of the user node in the supervisory node, the target factor is one of M first factors, and the M first factors are different; and the first signature message is obtained by signing a message to be signed based on the transaction voucher and at least one attribute parameter of multiple attribute parameters other than an attribute parameter used to represent an account address of the user node, where the multiple attribute parameters are used to represent different attributes of the user;

[0043] The legitimacy of the transaction voucher is verified based on the first proof.

[0044] The beneficial effects of the embodiments of the present application can be found in the relevant description of the first aspect and will not be repeated here.

[0045] In one embodiment, verifying the legitimacy of the transaction voucher based on the first certificate includes:

[0046] Sending a verification request to the supervisory node;

[0047] receiving a third list sent by the supervisory node, wherein the third list stores a plurality of certificates corresponding to at least one revoked transaction voucher;

[0048] If the first certificate sent by the user node is the same as any certificate in the third list, the transaction voucher is not valid.

[0049] In a fourth aspect, a device for protecting identity privacy is provided, which is applied to a user node and includes: a first processing unit;

[0050] The first processing unit is configured to:

[0051] Receiving a transaction credential, a first supervisory node identification code, and M first factors sent by the organization node, where the first supervisory identification code is used to identify the identity of the user node in the supervisory node, and the M first factors are different;

[0052] Generate a first certificate based on the first supervisory node identification code and a target factor, where the target factor is one of the M first factors;

[0053] A first signature message and the first certificate are sent to a transaction node, so that the transaction node verifies whether the transaction voucher is legitimate based on the first certificate, wherein the first signature message is obtained by signing a message based on the transaction voucher and at least one attribute parameter among multiple attribute parameters other than the attribute parameter used to represent the account address of the user node, wherein the multiple attribute parameters are used to represent different attributes of the user.

[0054] It can be understood that the beneficial effects of the fourth aspect can be found in the relevant description of the first aspect, and will not be repeated here.

[0055] In a fifth aspect, a device for protecting identity privacy is provided, which is applied to a supervisory node and includes: a second processing unit;

[0056] The second processing unit is configured to:

[0057] receiving a first organization node identification code sent by an organization node, where the first organization node identification code is used to identify an identity of a user node in the organization node;

[0058] Based on the first organization node identification code, generate a first supervisory node identification code and M first factors, where the first supervisory node identification code is used to identify the identity of the user node in the supervisory node, and the M first factors are different;

[0059] The first supervisory node identification code and the M first factors are sent to the organization node, so that the organization node determines the transaction certificate of the user node based on the first supervisory node identification code, and enables the user node to generate a first certificate based on the first supervisory node identification code and the target factor when using the transaction certificate to conduct a transaction, the target factor being one of the M first factors, and the first certificate being used to supervise the legitimacy of the transaction certificate.

[0060] It can be understood that the beneficial effects of the fifth aspect can be found in the relevant description of the second aspect, and will not be repeated here.

[0061] In a sixth aspect, a device for protecting identity privacy is provided, which is applied to a transaction node and includes: a third processing unit;

[0062] The third processing unit is configured to:

[0063] receiving a first certificate and first signature information sent by a user node, where the first certificate is obtained based on a first supervisory node identification code and a target factor, where the first supervisory node identification code is used to identify the identity of the user node in the supervisory node, the target factor is one of M first factors, and the M first factors are different; and the first signature message is obtained by signing a message to be signed based on the transaction voucher and at least one attribute parameter of multiple attribute parameters other than an attribute parameter used to represent an account address of the user node, where the multiple attribute parameters are used to represent different attributes of the user;

[0064] The legitimacy of the transaction voucher is verified based on the first proof.

[0065] It can be understood that the beneficial effects of the sixth aspect can be found in the relevant description of the third aspect, and will not be repeated here.

[0066] In the seventh aspect, a terminal device is provided, characterized in that it includes a memory, a processor, and a computer program stored in the memory and runnable on the processor, and when the processor executes the computer program, it implements the method for protecting identity privacy as described in any one of the first aspect, the second aspect, or the third aspect.

[0067] In an eighth aspect, a chip is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the method for protecting identity privacy according to any one of the first aspect, the second aspect, or the third aspect when executing the computer program.

[0068] In a ninth aspect, a computer readable storage medium is provided, which stores a computer program, wherein the computer program is executable by a processor to implement the method for protecting identity privacy according to any one of the first aspect, the second aspect, or the third aspect.

[0069] It can be understood that the beneficial effects of the above-mentioned seventh aspect, eighth aspect, and ninth aspect can be referred to the related description in the first aspect, the second aspect, and the third aspect, which will not be repeated here. BRIEF DESCRIPTION OF DRAWINGS

[0070] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the embodiments or prior art description will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0071] Figure 1 An application scenario of a method for protecting identity privacy provided by the embodiments of the present application.

[0072] Figure 2 An interaction diagram of a method for protecting identity privacy provided by the embodiments of the present application.

[0073] Figure 3 An interaction diagram of a specific process of updating a first factor provided by the embodiments of the present application.

[0074] Figure 4 An interaction diagram of a specific process of verifying a first proof provided by the embodiments of the present application.

[0075] Figure 5 A structure diagram of a device for protecting identity privacy provided by the embodiments of the present application.

[0076] Figure 6 A structure diagram of another device for protecting identity privacy provided by the embodiments of the present application.

[0077] Figure 7 A structure diagram of another device for protecting identity privacy provided by the embodiments of the present application.

[0078] Figure 8is a structural schematic diagram of a terminal device provided by an embodiment of the present application. DETAILED DESCRIPTION

[0079] In the following description, for the purposes of explanation and not limitation, specific details are set forth, such as particular system configurations, techniques, etc., in order to provide a thorough understanding of the embodiments of the present application. However, it will be apparent to those skilled in the art that the present application can be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known methods, devices, circuits, and

[0080] It should be understood that the term "comprises" when used in this specification and the appended claims, specifies the presence of stated features, integers, steps, operations, elements, and / or components, but does not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0081] It should also be understood that the term "and / or" when used in this specification and the appended claims, means any one of the associated listed items, or a combination of any combination of at least one of the associated listed items.

[0082] In this specification, the phrase "one or more embodiments of the present application" or "some embodiments of the present application" means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present application. Thus, the appearances of the phrases "in one or more embodiments of the present application" or "in some embodiments of the present application" in various places in the specification are not necessarily all referring to the same embodiment, unless otherwise specified. The terms "comprise," "comprises," "comprising," "include," "includes," "including," "contain," "contains," "containing," and the like mean "including but not limited to."

[0083] In addition, in the description of the specification and the appended claims, the terms "first", "second", and the like are used only to distinguish descriptions, and cannot be understood as indicating or implying relative importance.

[0084] In order to more clearly understand various implementations in the embodiments of the present application, the following first defines or explains the technical terms involved in the embodiments of the present application.

[0085] 1. Peterson Commitment: Peterson Commitment can be applied in scenarios such as audit verification to achieve the purpose of anonymous and confidential transactions. It can guarantee the validity of a transaction even if others do not know the amount and address. No one can find the amount and address information on a blockchain browser. The Peterson Commitment scheme is a two-phase interactive protocol. It consists of two phases: In the first phase, the committer randomly selects a blinding factor r and uses a formula to generate a commitment value c containing the original information v, and then sends the commitment value c to the verifier. In the second phase, the commitment is revealed. The committer sends the original information v and the blinding factor r to the verifier. The verifier then verifies whether the commitment value c sent by the committer in the first phase is equal to the value calculated by the verifier itself.

[0086] 2. Zero-knowledge proof: In cryptography, a zero-knowledge proof or zero-knowledge protocol is a method by which one party can prove to another that they know a value x without communicating any information. The essence of the zero-knowledge proof idea is that proving someone has knowledge of certain information by simply revealing that information is trivial. The challenge is to prove possession of this property without revealing the information itself or any other information.

[0087] 3. Hash Algorithm: A hash algorithm, also known as a digest algorithm, performs a calculation on any set of input data to produce a fixed-length output digest. The most important characteristic of a hash algorithm is that identical inputs always produce identical outputs, while different inputs are likely to produce different outputs. The purpose of a hash algorithm is to verify whether the original data has been tampered with. Therefore, a hash algorithm can verify that information is identical, saving time on duplicate file transfers. Furthermore, a hash algorithm can verify the authenticity of the owner of the information.

[0088] 4. Finite field elliptic curve algorithm: The finite field elliptic curve in this algorithm refers to the equation Coordinates It is an element in the finite field F. The finite field F is generally called the base field of the elliptic curve. There are generally two cases of the base field F. One is the order The finite field of is called the binary extension field, and Representation; one is a finite field with order p, called a prime field, represented by There is another very important concept in finite field elliptic curves, called generators. Simply put, given a point g on the elliptic curve, we can find a minimum n <p,使得对于任意k∈[1,n), ≠ ,and = .at this time, = , ,…, The n elliptic curve points obtained form a finite field elliptic curve group E( wherein, is defined as an infinite point, which is defined as zero element on the elliptic curve in mathematics. In cryptography, we actually use a finite field elliptic curve group E( ) with a given generator g, and the order of the group is n. This group E( ) is generally simply denoted as G.

[0089] As described in the background, the existing supervision method often causes the identity privacy of the user node to be exposed, and there is a great security risk. The specific reason is that in the existing supervision scheme, the organization node issues a transaction voucher for the user node, and the supervision node issues a legality proof of the transaction voucher for the user node, which is used to supervise the legality of the transaction voucher. The user signs the signature message based on at least one attribute parameter in the multiple attribute parameters other than the account address of the user node and the transaction voucher each time the user trades, and trades based on the signature message and the same legality proof. Multiple transactions sent by the same user are easily linked together through the same legality proof, so that after multiple transactions, a third party can easily determine that the multiple transactions come from the same user according to the same legality proof, and then crack the signature message through certain technical means, and then obtain all the attribute parameters of the user other than the account address. The third party can infer the identity information of the user through these attribute parameters, so that the identity privacy of the user is exposed.

[0090] In order to solve the above defects, the inventive concept of the present application is:

[0091] The first proof of the supervision transaction voucher provided by the user node to the transaction node when trading is generated based on the first supervision node identification code and the target factor. Since the target factor is one of the M first factors, and the M first factors are all different, the same user can generate multiple different proofs including the first proof through the first supervision node identification code and multiple first factors when trading multiple times. In this way, multiple different proofs can supervise the legality of the same transaction voucher. The same user can send multiple transactions using multiple different proofs, so that multiple transactions will not be linked together. Even after multiple transactions, the user exposes all the attribute parameters other than the account address, and the third party cannot know whether these attribute parameters come from the same user, thereby protecting the identity privacy of the user.

[0092] In order to illustrate the technical scheme of the present application, specific embodiments will be described below.

[0093] Please refer to Figure 1 , for example, Figure 1 As shown, Figure 1 A schematic diagram of an application scenario for a method for protecting identity privacy provided in an embodiment of the present application. For ease of illustration, only the portions relevant to this application are shown. This application scenario includes: a supervisory node 10, an organization node 20, multiple user nodes 30, and a transaction node 40. In some embodiments, the supervisory node 10, organization node 20, and multiple user nodes 30 may be network nodes. Specifically, they may be network nodes of terminal devices, service networks, and so on. In the embodiment of the present application, the transaction node 40 may be a blockchain node in a blockchain system.

[0094] When initiating transactions with the transaction node 40, multiple user nodes 30 need to request transaction credentials from the organization node 20. It should be noted that multiple user nodes 30 correspond to one organization node 20. When one of the multiple user nodes 30 needs to initiate a transaction, it requests a transaction credential from the organization node 20. Once the user node 30's request for a transaction credential is approved, it obtains the transaction credential. Each user node 30 has a transaction credential corresponding to it. Specifically, the user node 30 can be a desktop terminal or a mobile terminal. The mobile terminal can be a mobile phone, tablet computer, laptop computer, or the like.

[0095] The organization node 20 verifies the authenticity and legitimacy of the identity of the user node 30. When the user node 30 passes the verification, a first organization node identification code is generated in the organization node 20. The first organization node identification code is used to identify the identity of the user node 30 in the organization node; the organization node 20 applies for a first supervision node identification code from the supervision node 10 based on the first organization node identification code. The first supervision node identification code is used to identify the identity of the user node 30 in the supervision node. The organization node 20 generates a transaction certificate for the user node 30 based on the first supervision node identification code.

[0096] After receiving the application from the organization node 20, the supervisory node 10 generates a first supervisory node identification code and M first factors, and sends these to the organization node 20. The organization node 20 then sends the transaction voucher, the first supervisory node identification code, and the M first factors to the user node 30. The user node 30 then signs the message to be signed based on the transaction voucher to obtain a first signed message. The user node 30 generates a first certificate based on the first supervisory node identification code and one of the M first factors. The first certificate is used to monitor the legitimacy of the transaction voucher. For example, if the transaction voucher has not been revoked, the user node 30's use of the transaction voucher to trade is legal. If the transaction voucher has been revoked, the user node 30's use of the transaction voucher to trade is considered illegal.

[0097] The transaction node 40 is used to receive the first signature message and the first certificate sent by the user node 30, and verify the first signature message and the first certificate. The transaction can only be carried out after the first signature information and the first certificate are verified.

[0098] The following is a detailed description of a method for protecting identity privacy provided in an embodiment of the present application.

[0099] Please refer to Figure 2 , Figure 2 This is an interactive diagram of a method 200 for protecting identity privacy provided in an embodiment of the present application.

[0100] S201. The user node applies for a transaction certificate from the organization node.

[0101] It should be understood that in the embodiment of the present application, when a user node applies for a transaction credential from an organization node, the user node can first provide the organization node with multiple attribute parameters of the user and the user's identity proof, where the multiple attribute parameters are used to represent different attributes of the user, and each attribute parameter represents an attribute of the user.

[0102] In this embodiment of the present application, a user's attribute parameters may be determined by the blockchain system in which the user's node resides. It will be appreciated that the blockchain system can determine the type of attribute parameters set by the user's node and which attribute parameter is used to uniquely identify the user. The attribute parameters used to represent the user's unique identity are unique, and multiple attribute parameters of a user can indicate the identity of the user node. User nodes can define attribute parameters based on different blockchain systems. For example, attribute parameters of a user node can be set to include: account address, role information, public key, or affiliated organization. In this embodiment of the present application, the account address is the attribute parameter used to uniquely identify the user node. The account address of a user node can be a randomly generated string. This application does not impose any restrictions on the length of the account address string or the method by which the user node generates the string.

[0103] It should be noted that the organization to which the user node belongs is the blockchain system to which the user node and the organization node belong. Since the organization node and the user node are in the same blockchain system, the organization node is a party that the user node can fully trust. Therefore, when the user node sends information to the organization node, it does not need to encrypt the information. The user node directly sends the plaintext information to the organization node in the form of unencrypted plaintext information.

[0104] In an embodiment of the present application, when applying for a transaction certificate, the user node will generate a key pair and a random number. The user node will generate an identity certificate through calculation based on the public key of the organization node, the user node's own private key and the random number. For example, the method by which the user node calculates the identity certificate is completed through Peterson commitment in cryptography.

[0105] S202. The organization node verifies the eligibility of the user node to obtain the transaction certificate. After the verification is passed, the organization node applies to the supervision node for a first supervision node identification code.

[0106] In an embodiment of the present application, the process of the organization node verifying the qualifications of the user node to obtain credentials may include: the organization node can calculate a verification value based on the identity certificate and the organization node's own public key through the Peterson commitment in cryptography, and the organization node compares the verification value with the value of the identity certificate; if the verification value is equal to the value of the identity certificate, it means that the verification is passed; if the verification value is not equal to the identity certificate, it means that the verification is failed.

[0107] In this embodiment of the present application, after this verification is passed, the organization node will generate a first organization node identification code. It should be understood that the first organization node identification code can be a randomly generated string used to identify the identity of the user node in the organization node. This embodiment of the present application does not limit the length of the string or the method of generating a random number.

[0108] S203: The organizing node applies to the supervisory node for a first supervisory node identification code.

[0109] It should be understood that in order to ensure that the transaction certificate issued by the organization node is supervised by the supervision node, the organization node sends the first organization node identification code to the supervision node and applies for the first supervision node identification code based on the first organization node identification code.

[0110] In the embodiment of the present application, the first supervisory node identification code may be a randomly generated string of characters used to identify the identity of the user node in the supervisory node. The first supervisory node identification code corresponds to the first supervisory node identification code one by one.

[0111] S204: The supervisory node receives the first organization node identification code sent by the organization node.

[0112] S205. The supervisory node generates a first supervisory node identification code and M first factors based on the first organization node identification code.

[0113] In the embodiment of the present application, after receiving the first organization node identification code, the supervisory node generates a first supervisory node identification code and M first factors based on the first supervisory node identification code. The M first factors are all different.

[0114] It should be understood that the process of the supervisory node generating the first supervisory node identification code and M first factors based on the first organization node identification code includes: calculating the first organization node identification code to generate the first supervisory node identification code. In an embodiment of the present application, a hash algorithm can be used to calculate the first organization node identification code to generate the first supervisory node identification code. In an embodiment of the present application, a wired domain elliptic curve algorithm can be used to calculate the first organization node identification code within an epoch to generate M first factors. In an embodiment of the present application, the event length for generating M first factors is referred to as an epoch.

[0115] In some embodiments, the first factor is a generator.

[0116] S206. The supervisory node sends the first supervisory node identification code and M first factors to the organizing node.

[0117] S207. The organizing node generates a transaction voucher based on the first supervisory node identification code.

[0118] It should be understood that the process of generating a transaction voucher based on the first supervisory node identification code may include inputting the first supervisory node identification code into the CL signature algorithm to obtain the transaction voucher, where the CL signature is a Camenisch-Lysyanskaya signature, named after the author. Utilizing the CL signature algorithm can enhance the anonymity of the generated transaction voucher.

[0119] In the embodiment of the present application, the transaction voucher includes a zero-knowledge proof generated for all the user's attribute parameters, that is, all the user's attribute parameters only correspond to the same transaction voucher. The zero-knowledge proof is generated by the organization node based on the zero-knowledge proof concept.

[0120] It should be understood that compared to the method in which the organization node calculates and generates a corresponding zero-knowledge proof for each attribute parameter of the user, the method of generating transaction vouchers provided in the embodiment of the present application can greatly reduce the amount of computation required by the organization node to calculate the zero-knowledge proof.

[0121] S208. The user node receives the transaction certificate, the first supervisory node identification code, and the M first factors sent by the organization node.

[0122] It should be understood that the transaction voucher received by the user node is sent directly by the organization node, and the first supervisory node identification code and M first factors received by the user node are sent by the supervisory node through the organization node.

[0123] S209. The user node generates a first certificate based on the first supervisory node identification code and the target factor.

[0124] It should be understood that the first certificate is used to supervise the legitimacy of the transaction certificate.

[0125] In the embodiment of the present application, generating a first certificate based on the first supervisory node identification code and the target factor includes:

[0126] A first proof is generated based on the first supervisory node identification code and the target factor according to the following formula:

[0127]

[0128] in, Represents the first proof, represents the target factor, and r represents the first supervisory node identification code.

[0129] In this embodiment of the present application, the target factor is one of the M first factors, and the M first factors are all different. When the same user conducts multiple transactions, the above formula can be used to generate different first certificates based on the same first supervisory node identification code and different first factors.

[0130] The significance of generating different first proofs in user nodes is that multiple first proofs can monitor the legitimacy of the same transaction certificate. The same user can use multiple first proofs to send multiple transactions. This prevents the transactions from being linked together. Even if the user exposes all attribute parameters except the account address after multiple transactions, third parties cannot determine whether these attribute parameters originated from the same user, thus protecting the user's identity privacy.

[0131] S210. The user node sends a first signature message and a first certificate to the transaction node.

[0132] It should be understood that after receiving the transaction certificate, the first supervision node identification code and M first factors sent by the organization node, the user node signs the message to be signed based on the transaction certificate and at least one attribute parameter among multiple attribute parameters other than the attribute parameter used to represent the account address of the user node to obtain a first signed message.

[0133] In an embodiment of the present application, when a user node signs a message to be signed, it only needs to selectively disclose at least one attribute parameter (the disclosed attribute parameter cannot be an account address). The significance of only disclosing certain specific attribute parameters is that when a transaction node conducts a transaction, only certain specific attribute parameters are needed to obtain the transaction result. Therefore, the user node can only disclose certain specific attribute parameters, and the disclosed attribute parameters will not affect the personal privacy of the user node.

[0134] For example, the user node's attribute parameters include: the user node's account address, the user node's public key, the user node's role information, and the user node's affiliated organization. Therefore, when the user node signs a message to be signed, it can disclose only the role information without disclosing other information. The role information is at least one of the multiple attribute parameters other than the user node's account address.

[0135] For example, a user node does not need to disclose its account address, which uniquely identifies the user node. If the account address is disclosed, the user node's identity privacy is exposed. When the user node sends a transaction to a transaction node, the transaction node can track the user node through the account address, which violates the original intention of the embodiment of this application to protect the user node's identity privacy. Among them, the user node's account address is an attribute parameter used to uniquely identify the user node. The user node's account address can be a randomly generated string by the user node. This application does not restrict the length of the account address string or the method by which the user node generates the string.

[0136] In some embodiments, the first signed message is a signature generated by combining the CL signature and the zero-knowledge proof concept. CL signatures are used in zero-knowledge proof signature schemes to sign a set of data, thereby improving the anonymity of the signature and reducing the computational complexity of the signature. It should be noted that in the zero-knowledge proof concept, there are two participants, namely the prover and the verifier. The prover holds a secret, and the prover wants the verifier to believe that the verifier holds the secret, but does not want to disclose the secret to the verifier. Therefore, the prover and the verifier follow a protocol and, through a series of interactions, the verifier will eventually draw a clear conclusion, i.e., whether the prover holds the secret, without being able to know the content of the secret.

[0137] S211. The transaction node receives the first certificate and first signature information sent by the user node.

[0138] S212. The transaction node verifies the legitimacy of the transaction voucher based on the first proof.

[0139] It should be understood that in the embodiment of the present application, after the transaction node receives the first signed message and the first certificate sent by the user node, it first verifies the first certificate. If the first certificate verification fails, the transaction voucher is not legitimate. If the first certificate verification passes, the transaction voucher is legitimate. After the first certificate verification passes, the first signed message is verified. If the first signed message verification fails, the transaction fails. If the first signed message verification passes, the transaction is successful.

[0140] In this embodiment of the present application, the process of verifying the first signed message includes:

[0141] The transaction node calculates a second signature message through the CL signature scheme based on the public key of the organization node and at least one attribute parameter among multiple attribute parameters disclosed by the user node except the attribute parameter used to represent the account address of the user node, and compares the second signature message with the first signature message. If the second signature message is the same as the first signature message, the first signature message is verified; otherwise, the first signature message fails verification.

[0142] In the embodiment of the present application, the first proof of the regulatory transaction certificate provided by the user node to the transaction node during the transaction is generated based on the first regulatory node identification code and the target factor. Since the target factor is one of the M first factors, and the M first factors are all different, the same user can generate multiple different proofs including the first proof through the first regulatory node identification code and multiple first factors during multiple transactions. In this way, multiple different proofs can supervise the legitimacy of the same transaction certificate. The same user can use multiple different proofs to send multiple transactions, so that multiple transactions will not be linked together. Even if the user exposes all attribute parameters except the account address after multiple transactions, a third party cannot know whether these attribute parameters come from the same user, thereby protecting the user's identity privacy.

[0143] In some embodiments, when the same user conducts multiple transactions, different multiple certificates are generated based on the first supervisory node identification code and different first factors. However, if there are not enough first factors to generate different multiple certificates, for example, the same user wants to conduct 5 transactions but only receives 4 first factors from the supervisory node, then the user will notify the supervisory node to update the first factor through the user node. For the specific update process, please refer to Figure 3 , Figure 3 This is an interactive diagram of a specific process of updating a first factor provided by an embodiment of the present application.

[0144] S301: The user node stores the target factor in the first list.

[0145] It should be understood that the user node is configured with a first list, which is used to store the first factor corresponding to each of the multiple certificates. In some embodiments, in order to save storage space of the user node, the first list only stores the identifier of each first factor.

[0146] S302: If the first list includes M first factors, send an update message to the supervision node.

[0147] In an embodiment of the present application, the user node generates a first certificate based on the first supervisory node identification code and the target factor for each transaction, and stores the target factor corresponding to the first certificate generated for each transaction in the first list. If the first list includes M first factors, it proves that the user node has used up the M first factors that can generate different certificates when using the same transaction voucher for transactions. If any one of the M first factors is continued to be used to generate the first certificate, the user will use the same first certificate to trade in different transactions, which may easily lead to the leakage of identity privacy.

[0148] In order to prevent the leakage of identity privacy, in the embodiment of the present application, when the first list includes M first factors, an update message is sent to the supervisory node to request the supervisory node to update the M first factors.

[0149] S303: The supervisory node receives the update message sent by the user node.

[0150] S304: The supervisory node updates the M first factors according to the update message.

[0151] It should be understood that in other embodiments, the first organization node identification code may be calculated using a wired domain elliptic curve algorithm within an epoch to generate M first factors. Therefore, updating the M first factors in this embodiment of the present application may be performed by updating the M first factors based on the wired domain elliptic curve algorithm within different epochs. This embodiment of the present application does not limit the method for updating the M first factors.

[0152] S305: The supervisory node sends the updated multiple first factors to the user node through the organization node.

[0153] S306: The user node receives the updated multiple first factors sent by the supervisory node through the organization node.

[0154] In an embodiment of the present application, after the user node receives the updated multiple first factors sent by the supervisory node through the organization node, it generates different first proofs based on the updated multiple first factors. In this way, the same user always uses different first proofs to trade when conducting multiple transactions, thereby protecting the user's identity privacy.

[0155] In some embodiments, to further protect the user's identity privacy, when the first list includes M first factors, the organization node is notified to update the transaction credentials, and the transaction node is notified to update the first supervisory node identification code. A signature message is signed based on the updated transaction credentials and at least one of multiple attribute parameters other than the attribute parameter representing the user node's account address, resulting in an updated signature message. An updated first proof is generated based on the updated first supervisory node identification code and the first factor. This allows the same user to use different signature messages and first proofs for multiple transactions, further protecting the user's identity privacy.

[0156] In some embodiments, the process of the transaction node verifying the first proof is as follows: Figure 4 , Figure 4 It is an interactive diagram of the specific process of verifying the first proof provided in an embodiment of the present application.

[0157] S401. The user node sends a first certificate to the transaction node.

[0158] S402: The transaction node sends a verification request to the supervisory node.

[0159] S403: The supervisory node receives the verification request sent by the transaction node.

[0160] S404. The supervisory node determines multiple certificates corresponding to each supervisory node identification code based on each supervisory node identification code in the N supervisory node identification codes in the second list and multiple first factors corresponding to each supervisory node identification code.

[0161] It should be understood that the second list stores the supervisory node identification code corresponding to at least one revoked transaction certificate, and the first supervisory node identification code is one of N supervisory node identification codes.

[0162] S405. The supervisory node sends the third list to the transaction node.

[0163] It should be understood that the third list stores multiple certificates corresponding to at least one revoked transaction credential.

[0164] Exemplarily, the data in the third list is obtained in the following manner:

[0165] Based on the supervisory node identification code corresponding to the at least one revoked transaction certificate stored in the second list and the multiple first factors corresponding to each supervisory node identification code, multiple certificates corresponding to the at least one revoked transaction certificate are obtained.

[0166] For example, there are three supervisory node identification codes corresponding to the revoked transaction vouchers stored in the second list, namely supervisory node identification code A, supervisory node identification code B and supervisory node identification code C. Supervisory node identification code A corresponds to three first factors, supervisory node identification code B corresponds to four first factors, and supervisory node identification code C corresponds to five first factors. Substituting supervisory node identification code A and the three first factors into the formula , and we get 3 proofs. Among them, R stands for proof, represents the first factor, Represents the supervisory node identification code.

[0167] Similarly, substitute the supervisory node identifier B and the four first factors into the formula , we get 4 proofs, and substitute the supervisory node identification code C and the 5 first factors into the formula , we get 5 proofs, so the third list contains 12 proofs.

[0168] S406. The transaction node receives the third list sent by the supervisory node. If the first certificate sent by the user node is the same as any certificate in the third list, the transaction voucher is not legal.

[0169] It should be understood that the third list stores multiple certificates corresponding to at least one revoked transaction certificate. Therefore, when the first certificate sent by the user node is the same as any certificate in the third list, it proves that the transaction certificate corresponding to the first certificate sent by the user node has been revoked. The revoked transaction certificate is not legal. When a transaction is conducted using the revoked transaction certificate, the transaction is not legal, and the transaction node will cancel the transaction, causing the transaction to fail.

[0170] When the first certificate sent by the user node is different from any certificate in the third list, it proves that the transaction certificate corresponding to the first certificate sent by the user node has not been revoked, and the transaction certificate is legal. When a transaction is conducted using an unrevoked transaction certificate, the transaction is legal, and the transaction node will not cancel the transaction.

[0171] In an embodiment of the present application, the transaction node uses multiple certificates corresponding to at least one revoked transaction certificate stored in the third list to verify the first certificate sent by the user node, and can verify whether the transaction certificate corresponding to the first certificate has been revoked. When the transaction certificate has been revoked, the transaction is canceled, thereby preventing the occurrence of abnormal transactions in the blockchain and improving the security of blockchain transactions.

[0172] In some embodiments, the data in the second list is obtained by:

[0173] The supervisory node receives the revocation evidence and the first organization node identification code; if the revocation evidence passes verification, determines the first supervisory node identification code corresponding to the first organization node identification code in the fourth list; and stores the first supervisory node identification code in the second list.

[0174] It should be understood that a fourth list is configured in the supervisory node, and the fourth list contains at least one supervisory node identification code and at least one organization node identification code, and the at least one supervisory node identification code and the at least one organization node identification code have a one-to-one correspondence.

[0175] In this embodiment of the present application, when each user applies for a transaction voucher through a user node, the supervisory node stores the organization node identification code received from the organization node and the supervisory node identification code corresponding to the organization node identification code generated by itself in the fourth list. Therefore, the fourth list contains at least one supervisory node identification code and at least one organization node identification code. Exemplarily, the fourth list can be expressed as:

[0176] Table 1

[0177]

[0178] The data in the second list provided in the embodiment of the present application is obtained in one of the revocation scenarios among many revocation scenarios, and the revocation scenario may be:

[0179] When the organizing node discovers that the user itself or a third party uses the obtained transaction certificate to conduct abnormal transactions, the organizing node sends the revocation evidence and the organizing node identification code corresponding to the obtained transaction certificate to the supervision node. The supervision node verifies the revocation evidence. After the verification is passed, it searches for the supervision node identification code corresponding to the organizing node identification code corresponding to the obtained transaction certificate in the second list, and stores the supervision node identification code corresponding to the organizing node identification code corresponding to the obtained transaction certificate in the second list.

[0180] For example, the revocation evidence can be a statement customized by the organization node, which is used to declare that the transaction conducted by the user or a third party using the obtained transaction voucher is an abnormal transaction. When verifying the revocation evidence, the authenticity and sufficiency of the evidence are mainly verified.

[0181] In some embodiments, the data in the second list can also be obtained in other revocation scenarios. For example, another revocation scenario may be: when other users discover that the user who has obtained the transaction voucher or a third party has conducted an abnormal transaction, the user node sends the revocation evidence, the first proof, and the target factor to the supervisory node. In this scenario, the data in the second list can also be obtained in the following ways:

[0182] The supervisory node receives the revocation evidence, the first proof and the target factor; if the revocation evidence passes the verification, the second proof is determined based on the target factor and at least one supervisory node identification code in the fourth list; if the first proof is the same as the second proof, the supervisory node identification code corresponding to the second proof is stored in the second list.

[0183] It should be understood that the revocation evidence can be a statement customized by the user node, which can be used to declare that the transaction conducted by the user or a third party using the obtained transaction certificate is an abnormal transaction. The statement can also be used to declare that the obtained transaction certificate has been lost.

[0184] When the revocation evidence is verified, first, the supervisory node calculates multiple proofs based on the target factor and all supervisory node identification codes in the fourth list. The specific calculation can be done through the formula Perform calculations.

[0185] Next, the plurality of certificates are searched for a certificate identical to the first certificate. If there is a certificate identical to the first certificate among the plurality of certificates, the supervisory node identification code corresponding to the certificate identical to the first certificate is stored in the second list. In this embodiment of the present application, a certificate identical to the first certificate among the plurality of certificates may be referred to as the second certificate.

[0186] In some embodiments, another revocation scenario may also be: the supervisory node discovers that the user node has used the obtained transaction voucher to conduct an abnormal transaction. In this scenario, the data in the second list can also be obtained in the following way:

[0187] The supervisory node determines a supervisory node identifier corresponding to the obtained transaction voucher, and stores the supervisory node identifier corresponding to the obtained transaction voucher in a second list.

[0188] In some implementations, another revocation scenario may be: a user who has obtained a transaction voucher loses the transaction voucher. In this scenario, the data in the second list may also be obtained in the following manner:

[0189] The supervisory node identifier and revocation evidence corresponding to the obtained transaction voucher are sent to the supervisory node through the user node. If the revocation evidence is verified, the supervisory node identifier corresponding to the obtained transaction voucher is stored in the second list.

[0190] It should be understood that the revocation evidence can be a statement customized by the user node, and the statement can also be used to declare that the obtained transaction certificate has been lost.

[0191] It should be understood that Figure 4When the transaction node verifies the first proof, it compares the first proof with multiple proofs corresponding to at least one revoked transaction voucher stored in the third list. In other embodiments, verification can also be performed in other ways, for example:

[0192] When the transaction node sends a verification request to the regulatory node, the regulatory agency removes the regulatory node identification code corresponding to at least one revoked transaction certificate from the fourth list to obtain a fifth list. The transaction certificates corresponding to the multiple regulatory node identification codes included in the fifth list are all transaction certificates that have not been revoked.

[0193] The regulatory authority determines multiple certificates corresponding to each regulatory node identification code based on each regulatory node identification code in the multiple regulatory node identification codes in the fifth list and the multiple first factors corresponding to each regulatory node identification code, and stores the multiple certificates corresponding to each regulatory node identification code in the sixth list, which stores multiple certificates corresponding to at least one transaction voucher that has not been revoked.

[0194] The supervisory node sends the fifth list to the transaction node, and the transaction node receives the sixth list sent by the supervisory node. If the first proof sent by the user node is the same as any proof in the sixth list, the transaction certificate is legal.

[0195] It should be understood that the sixth list stores multiple certificates corresponding to at least one unrevoked transaction certificate. Therefore, when the first certificate sent by the user node is the same as any certificate in the sixth list, it proves that the transaction certificate corresponding to the first certificate sent by the user node has not been revoked, and the unrevoked transaction certificate is legal.

[0196] When the first certificate sent by the user node is different from any certificate in the sixth list, it proves that the transaction certificate corresponding to the first certificate sent by the user node has been revoked and the transaction certificate is not legal. When a transaction is conducted using a revoked transaction certificate, the transaction is abnormal and the transaction node will cancel the transaction, causing the transaction to fail.

[0197] In an embodiment of the present application, the transaction node uses multiple certificates corresponding to at least one unrevoked transaction certificate stored in the sixth list to verify the first certificate sent by the user node, and can verify whether the transaction certificate corresponding to the first certificate has not been revoked. When the transaction certificate has not been revoked, the transaction proceeds normally. When the transaction certificate has been revoked, the transaction is canceled, thereby preventing the occurrence of abnormal transactions in the blockchain and improving the security of blockchain transactions.

[0198] It should be understood that the size of the serial numbers of the steps in the above embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0199] Please refer to Figure 5 , Figure 5 1 is a structural diagram of a device 50 for protecting identity privacy provided in an embodiment of the present application. The device is applied to a user node and includes: a first processing unit 51.

[0200] The first processing unit 51 is used to:

[0201] Receive the transaction certificate, the first supervisory node identification code, and M first factors sent by the organization node. The first supervisory identification code is used to identify the identity of the user node in the supervisory node. The M first factors are different.

[0202] Generate a first certificate based on the first supervisory node identification code and the target factor, where the target factor is one of the M first factors;

[0203] A first signature message and a first certificate are sent to the transaction node, so that the transaction node verifies the legitimacy of the transaction certificate based on the first certificate. The first signature message is obtained by signing the signature message based on the transaction certificate and at least one attribute parameter of multiple attribute parameters other than the attribute parameter used to represent the account address of the user node. The multiple attribute parameters are used to characterize different attributes of the user.

[0204] The first processing unit 51 is further configured to:

[0205] Store the target factors in the first list;

[0206] If the first list includes M first factors, sending an update message to the supervisory node so that the supervisory node updates the M first factors;

[0207] The updated multiple first factors are received from the supervisory node through the organizing node.

[0208] The first processing unit 51 is further configured to:

[0209] A first proof is generated based on the first supervisory node identification code and the target factor according to the following formula:

[0210]

[0211] in, Represents the first proof, represents the target factor, and r represents the code generated by the first supervisory node.

[0212] Please refer to Figure 6 , Figure 6 1 is a structural diagram of another device 60 for protecting identity privacy provided in an embodiment of the present application. The device is applied to a supervision node and includes: a second processing unit 61.

[0213] The second processing unit 61 is used for:

[0214] receiving a first organization node identification code sent by the organization node, where the first organization node identification code is used to identify the identity of the user node in the organization node;

[0215] Based on the first organization node identification code, generate a first supervisory node identification code and M first factors, where the first supervisory node identification code is used to identify the identity of the user node in the supervisory node, and the M first factors are different;

[0216] The first supervisory node identification code and M first factors are sent to the organization node, so that the organization node determines the transaction certificate of the user node based on the first supervisory node identification code, and enables the user node to generate a first certificate based on the first supervisory node identification code and the target factor when using the transaction certificate to conduct a transaction. The target factor is one of the M first factors, and the first certificate is used to supervise the legitimacy of the transaction certificate.

[0217] The second processing unit 61 is further configured to:

[0218] Receive update messages sent by user nodes;

[0219] Update the M first factors according to the update message;

[0220] The updated multiple first factors are sent to the user node through the organization node.

[0221] The second processing unit 61 is further configured to:

[0222] Receive verification requests sent by transaction nodes;

[0223] Determining multiple certifications corresponding to each supervisory node identification code based on each supervisory node identification code in the N supervisory node identification codes in the second list and multiple first factors corresponding to each supervisory node identification code, wherein the second list stores a supervisory node identification code corresponding to at least one revoked transaction voucher, and the first supervisory node identification code is one of the N supervisory node identification codes;

[0224] A third list is sent to the transaction node, so that the transaction node verifies whether the transaction certificate of the user node is legitimate based on the third list, and the third list includes multiple certificates.

[0225] The supervisory node is configured with a fourth list, which includes at least one supervisory node identification code and at least one organization node identification code. The at least one supervisory node identification code and the at least one organization node identification code have a one-to-one correspondence. The second processing unit 61 is further configured to:

[0226] receiving revocation evidence and the first organization node identification code;

[0227] If the revocation evidence passes verification, determining the first supervisory node identification code corresponding to the first organization node identification code in the fourth list;

[0228] The first supervisory node identification code is stored in the second list.

[0229] The supervisory node is configured with a fourth list, which includes at least one supervisory node identification code and at least one organization node identification code. The at least one supervisory node identification code and the at least one organization node identification code have a one-to-one correspondence. The second processing unit 61 is further configured to:

[0230] receiving the revocation evidence, the first proof, and the target factor;

[0231] If the revocation evidence is verified, determining a second proof based on the target factor and at least one supervisory node identification code in the fourth list;

[0232] If the first proof is identical to the second proof, the supervisory node identification code corresponding to the second proof is stored in the second list.

[0233] Please refer to Figure 7 , Figure 7 1 is a structural diagram of another device 70 for protecting identity privacy provided in an embodiment of the present application. The device is applied to a transaction node and includes: a third processing unit 71.

[0234] The third processing unit 71 is used for:

[0235] Receive a first certificate and first signature information sent by the user node, where the first certificate is obtained based on a first supervisory node identification code and a target factor, where the first supervisory node identification code is used to identify the identity of the user node in the supervisory node, and the target factor is one of M first factors, where the M first factors are different. The first signature message is obtained by signing a message to be signed based on the transaction voucher and at least one attribute parameter of multiple attribute parameters other than the attribute parameter used to represent the account address of the user node, where the multiple attribute parameters are used to represent different attributes of the user;

[0236] The legitimacy of the transaction certificate is verified based on the first proof.

[0237] The third processing unit 71 is further configured to:

[0238] Send a verification request to the supervisory node;

[0239] receiving a third list sent by the supervisory node, wherein the third list stores multiple certificates corresponding to at least one revoked transaction voucher;

[0240] If the first proof sent by the user node is the same as any proof in the third list, the transaction certificate is not valid.

[0241] Those skilled in the art can clearly understand that, for the convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiment can be integrated into one processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the units and modules in the above-mentioned system can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here.

[0242] like Figure 8 As shown, an embodiment of the present application also provides a terminal device 80, including a memory 81, a processor 82, and a computer program 83 stored in the memory 81 and executable on the processor 22. When the processor 82 executes the computer program 83, the methods for protecting identity privacy of the above-mentioned embodiments are implemented.

[0243] The processor 82 may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0244] The memory 81 can be an internal storage unit of the terminal device 80. Alternatively, the memory 81 can be an external storage device of the terminal device 80, such as a plug-in hard drive, a Smart Media Card (SMC), a Secure Digital (SD) card, a flash memory card, etc. equipped on the terminal device 80. Furthermore, the memory 81 can include both an internal storage unit of the terminal device 80 and an external storage device. The memory 81 is used to store computer programs and other programs and data required by the terminal device 80. The memory 81 can also be used to temporarily store data that has been output or is about to be output.

[0245] An embodiment of the present application also provides a chip, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the methods for protecting identity privacy in the above embodiments are implemented.

[0246] An embodiment of the present application further provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, the method for protecting identity privacy in the above embodiments is implemented.

[0247] An embodiment of the present application provides a computer program product. When the computer program product is run on a mobile terminal, the mobile terminal implements the methods for protecting identity privacy of the above embodiments when executing the computer program product.

[0248] If the integrated unit is implemented as a software functional unit and sold or used as a standalone product, it can be stored in a computer-readable storage medium. Based on this understanding, the present application can implement all or part of the process steps in the above-mentioned method embodiments by using a computer program to instruct the relevant hardware. The computer program can be stored in a computer-readable storage medium. When executed by a processor, the computer program can implement the steps of each of the above-mentioned method embodiments. The computer program includes computer program code, which can be in source code form, object code form, executable file, or some intermediate form. The computer-readable storage medium can include at least: any entity or device capable of carrying the computer program code to the camera / terminal device, recording medium, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunications signals, and software distribution media. Examples include a USB flash drive, a removable hard drive, a magnetic disk, or an optical disk.

[0249] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant description of other embodiments.

[0250] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0251] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the embodiments of the present application.

[0252] The above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present application, and should all be included in the scope of protection of the present application.

Claims

1. A method for protecting identity privacy, applied to a user node, characterized in that: include: receiving a transaction credential, a first supervisory node identification code, and M first factors sent by the organization node, where the first supervisory node identification code is used to identify the identity of the user node in the supervisory node, and the M first factors are different; Generate a first certificate based on the first supervisory node identification code and a target factor, where the target factor is one of the M first factors; A first signature message and the first certificate are sent to a transaction node, so that the transaction node verifies whether the transaction voucher is legitimate based on the first certificate, wherein the first signature message is obtained by signing a message based on the transaction voucher and at least one attribute parameter among multiple attribute parameters other than the attribute parameter used to represent the account address of the user node, wherein the multiple attribute parameters are used to represent different attributes of the user.

2. The method according to claim 1, characterized in that The method further comprises: storing the target factor in a first list; If the first list includes the M first factors, sending an update message to the supervisory node so that the supervisory node updates the M first factors; Receive the updated multiple first factors sent by the supervisory node through the organizing node.

3. The method according to claim 1 or 2, characterized in that The generating a first certificate based on the first supervisory node identification code and the target factor includes: A first proof is generated based on the first supervisory node identification code and the target factor according to the following formula: in, Representing the first proof, represents the target factor, and r represents the first supervisory node identification code.

4. A method for protecting identity privacy, applied to a supervisory node, characterized in that: include: receiving a first organization node identification code sent by an organization node, where the first organization node identification code is used to identify an identity of a user node in the organization node; Based on the first organization node identification code, generate a first supervisory node identification code and M first factors, where the first supervisory node identification code is used to identify the identity of the user node in the supervisory node, and the M first factors are different; The first supervisory node identification code and the M first factors are sent to the organization node, so that the organization node determines the transaction certificate of the user node based on the first supervisory node identification code, and enables the user node to generate a first certificate based on the first supervisory node identification code and the target factor when using the transaction certificate to conduct a transaction, the target factor being one of the M first factors, and the first certificate being used to supervise the legitimacy of the transaction certificate.

5. The method according to claim 4, characterized in that The method further comprises: Receiving an update message sent by the user node; Updating the M first factors according to the update message; The updated plurality of first factors are sent to the user node through the organization node.

6. The method according to claim 4 or 5, characterized in that The method further comprises: Receive verification requests sent by transaction nodes; Determining, based on each supervisory node identification code in N supervisory node identification codes in a second list and multiple first factors corresponding to each supervisory node identification code, multiple certifications corresponding to each supervisory node identification code, wherein the second list stores a supervisory node identification code corresponding to at least one revoked transaction credential, and the first supervisory node identification code is one of the N supervisory node identification codes; A third list is sent to the transaction node, so that the transaction node verifies whether the transaction certificate of the user node is legitimate based on the third list, wherein the third list includes the multiple certificates.

7. The method according to claim 6, characterized in that The supervisory node is configured with a fourth list, the fourth list including at least one supervisory node identification code and at least one organization node identification code, the at least one supervisory node identification code and the at least one organization node identification code being in one-to-one correspondence, and the method further comprising: receiving revocation evidence and the first organization node identification code; If the revocation evidence passes verification, determining the first supervisory node identification code corresponding to the first organization node identification code in the fourth list; The first supervisory node identification code is stored in the second list.

8. The method according to claim 6, characterized in that The supervisory node is configured with a fourth list, the fourth list including at least one supervisory node identification code and at least one organization node identification code, the at least one supervisory node identification code and the at least one organization node identification code being in one-to-one correspondence, and the method further comprising: receiving a revocation evidence, the first proof, and the target factor; If the revocation evidence passes verification, determining a second proof based on the target factor and the at least one supervisory node identification code in the fourth list; If the first certificate is the same as the second certificate, the supervisory node identification code corresponding to the second certificate is stored in the second list.

9. A method for protecting identity privacy, applied to a transaction node, characterized in that: include: Receiving a first certificate and a first signed message sent by a user node, where the first certificate is obtained by the user node based on a first supervisory node identification code and a target factor, where the first supervisory node identification code is used to identify the identity of the user node in the supervisory node, and the target factor is one of M first factors sent by the organization node to the user node, where the M first factors are different; and the first signed message is obtained by signing a message to be signed in the user node based on a transaction voucher sent by the organization node to the user node and at least one attribute parameter of multiple attribute parameters other than an attribute parameter used to represent an account address of the user node, where the multiple attribute parameters are used to represent different attributes of the user; The legitimacy of the transaction voucher is verified based on the first proof.

10. The method according to claim 9, characterized in that The verifying whether the transaction voucher is legitimate based on the first certificate includes: Sending a verification request to the supervisory node; receiving a third list sent by the supervisory node, wherein the third list stores a plurality of certificates corresponding to at least one revoked transaction voucher; If the first certificate sent by the user node is the same as any certificate in the third list, the transaction voucher is not valid.

11. A terminal device, characterized in that: The invention comprises a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the computer program, the method for protecting identity privacy according to any one of claims 1 to 3, 4 to 8, or 9 to 10 is implemented.

Images