WO2020192236A1 - 基于盲签名的交易方法及装置 - Google Patents

基于盲签名的交易方法及装置 Download PDF

Info

Publication number
WO2020192236A1
WO2020192236A1 PCT/CN2020/070109 CN2020070109W WO2020192236A1 WO 2020192236 A1 WO2020192236 A1 WO 2020192236A1 CN 2020070109 W CN2020070109 W CN 2020070109W WO 2020192236 A1 WO2020192236 A1 WO 2020192236A1
Authority
WO
WIPO (PCT)
Prior art keywords
signature
result
providing node
payment client
blinding
Prior art date
Application number
PCT/CN2020/070109
Other languages
English (en)
French (fr)
Inventor
张�林
黄海泉
孙海波
Original Assignee
北京沃东天骏信息技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 北京沃东天骏信息技术有限公司 filed Critical 北京沃东天骏信息技术有限公司
Priority to EP20777894.5A priority Critical patent/EP3893178B1/en
Publication of WO2020192236A1 publication Critical patent/WO2020192236A1/zh
Priority to US17/370,742 priority patent/US20210334809A1/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4014—Identity check for transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • G06Q20/0655—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash e-cash managed centrally
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3825—Use of electronic signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/389—Keeping log of transactions for guaranteeing non-repudiation of a transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/088—Usage controlling of secret information, e.g. techniques for restricting cryptographic keys to pre-authorized uses, different access levels, validity of crypto-period, different key- or password length, or different strong and weak cryptographic algorithms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H04L9/3257—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures using blind signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2220/00—Business processing using cryptography
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

Definitions

  • the embodiments of the present application relate to computer technology, and in particular to a transaction method and device based on blind signature.
  • Blockchain is a disintermediation database. In the process of transactions based on blockchain, the blockchain provides a publicly visible, tamper-resistant, and decentralized system for both parties of the transaction.
  • both parties of the transaction upload transaction-related information containing the address information of both parties to the transaction to the blockchain, and the nodes in the blockchain verify the transaction based on the transaction-related information. After the verification is passed Control transaction completion.
  • the eavesdropper can obtain the private information of both parties to the transaction based on the address information, which leads to security problems in the transaction process.
  • the embodiments of the present application provide a transaction method and device based on blind signatures to overcome the security problems of both parties in the blockchain transaction process.
  • an embodiment of the present application provides a transaction method based on blind signature, including:
  • the money providing node receives the first signature request sent by the payment client, the first signature request carries a blinding result, and the blinding result is the result of the blinding process performed by the payment client according to transaction service parameters and signature data ;
  • the currency providing node signs the blinding result to obtain a first signature result, and sends the first signature result to the payment client;
  • the money providing node receives the signature data and the second signature result sent by the receiving client, and completes the transaction after the signature data and the second signature result are verified, wherein the signature data and the second signature result
  • the signature result is sent by the payment client to the payment client, and the second signature result is a result obtained by deblinding the first signature result.
  • the method before the money providing node receives the first signature request sent by the payment client, the method further includes:
  • the currency providing node signs the transaction service parameters to obtain a third signature result
  • the blinding result is the result of the blinding process performed by the payment client according to the third signature result and the signature data.
  • the currency providing node before completing the transaction after the verification of the signature data and the second signature result, the currency providing node further includes:
  • the money providing node determines that the signature data received from the payment client is not in the signature data list
  • the currency providing node verifies the second signature result and the signature data according to a preset model, and obtains a verified result.
  • the currency providing node verifies the second signature result and the signature data according to a preset model, and obtains the result of the verification, including:
  • the currency providing node uses the second signature result and the signature data as the input of the preset model
  • the currency providing node determines whether the preset model satisfies the equation relationship, and if so, determines that the verification is passed.
  • the method before the money providing node receives the first signature request sent by the payment client, the method further includes:
  • the money providing node receives the digital asset sent by the payment client
  • the completion of the transaction by the currency providing node after the verification of the signature data and the second signature result is passed including:
  • the money providing node pays the digital asset to the collection client.
  • an embodiment of the present application provides a blind signature-based transaction method, including:
  • the payment client performs blinding processing according to transaction service parameters and signature data, and obtains the blinding result
  • the payment client sends a first signature request to the money providing node, where the first signature request carries the blinding result;
  • the payment client receives the first signature result sent by the money providing node, where the first signature result is a result obtained by the money providing node signing the blinding result;
  • the payment client deblinds the first signature result to obtain a second signature result, and sends the second signature result and the signature data to the payment client.
  • the method before the payment client performs blinding processing according to transaction service parameters and signature data to obtain the blinding result, the method further includes:
  • the payment client receives a third signature result sent by the money providing node, where the third signature result is a result obtained by the money providing node signing the transaction service parameter;
  • the payment client performs blinding processing according to transaction service parameters and signature data to obtain a blinding result, including:
  • the payment client performs blinding processing according to the third signature result and the signature data to obtain the blinding result.
  • the payment client performs blinding processing according to transaction service parameters and signature data, and before obtaining the blinding result, it further includes:
  • the payment client sends digital assets to the currency providing node.
  • an embodiment of the present application provides a blind signature-based transaction device, including:
  • the receiving module is configured to receive the first signature request sent by the payment client by the money providing node, where the first signature request carries a blinding result, and the blinding result is that the payment client performs blinding according to transaction service parameters and signature data.
  • the result of chemical treatment is configured to receive the first signature request sent by the payment client by the money providing node, where the first signature request carries a blinding result, and the blinding result is that the payment client performs blinding according to transaction service parameters and signature data.
  • a signature module used by the currency providing node to sign the blinding result to obtain a first signature result, and send the first signature result to the payment client;
  • the transaction module is used for the money providing node to receive the signature data and the second signature result sent by the receiving client, and complete the transaction after the signature data and the second signature result are verified, wherein the signature data And the second signature result is sent by the payment client to the collection client, and the second signature result is a result obtained by deblinding the first signature result.
  • the receiving module is also used for:
  • the currency providing node signs the transaction service parameters to obtain a third signature result
  • the blinding result is the result of the blinding process performed by the payment client according to the third signature result and the signature data.
  • the receiving module is also used for:
  • the money providing node determines that the signature data received from the payment client is not in the signature data list
  • the currency providing node verifies the second signature result and the signature data according to a preset model, and obtains a verified result.
  • the transaction module is specifically used for:
  • the currency providing node uses the second signature result and the signature data as the input of the preset model
  • the currency providing node determines whether the preset model satisfies the equation relationship, and if so, determines that the verification is passed.
  • the receiving module is also used for:
  • the money providing node receives the digital asset sent by the payment client
  • the transaction module is also used for:
  • the money providing node pays the digital asset to the collection client.
  • an embodiment of the present application provides a blind signature-based transaction device, including:
  • the blinding module is used for the payment client to perform blinding processing according to transaction service parameters and signature data to obtain the blinding result;
  • a sending module used for the payment client to send a first signature request to the money providing node, where the first signature request carries the blinding result
  • the deblinding module is used for the payment client to deblind the first signature result to obtain a second signature result, and send the second signature result and the signature data to the payment client.
  • the sending module is also used for:
  • the payment client receives a third signature result sent by the money providing node, where the third signature result is a result obtained by the money providing node signing the transaction service parameter;
  • the blinding module is specifically used for:
  • the payment client performs blinding processing according to the third signature result and the signature data to obtain the blinding result.
  • the sending module is specifically used for:
  • the payment client sends digital assets to the currency providing node.
  • an embodiment of the present application provides a blind signature-based transaction device, including:
  • Memory used to store programs
  • the processor is configured to execute the program stored in the memory, and when the program is executed, the processor is configured to execute the method described in the above first aspect and any of the various possible designs of the first aspect.
  • an embodiment of the present application provides a blind signature-based transaction device, including:
  • Memory used to store programs
  • the processor is configured to execute the program stored in the memory, and when the program is executed, the processor is configured to execute the method described in the above second aspect and any of the various possible designs of the second aspect.
  • an embodiment of the present application provides a computer-readable storage medium, including instructions, which when run on a computer, cause the computer to execute the above-mentioned first aspect and any of the various possible designs of the first aspect method.
  • embodiments of the present application provide a computer-readable storage medium, including instructions, which when run on a computer, cause the computer to execute the above-mentioned first aspect and any of the various possible designs of the first aspect method.
  • the embodiments of the present application provide a transaction method and device based on blind signatures.
  • the method includes: a payment client performs blinding processing according to transaction service parameters and signature data to obtain a blinding result.
  • the payment client sends a first signature request to the currency providing node, and the first signature request carries the blinding result.
  • the money providing node receives the first signature request sent by the payment client, signs the blinding result, and obtains the first signature result.
  • the currency providing node sends the first signature result to the payment client.
  • the payment client receives the first signature result sent by the currency providing node.
  • the payment client deblinds the first signature result, obtains the second signature result, and sends the second signature result and the signature data to the payment client.
  • the receiving client sends the second signature result and signature data to the money providing node.
  • the money providing node receives the signature data and the second signature result sent by the receiving client, and completes the transaction after the signature data and the second signature result are verified.
  • the signature data and the second signature result are sent to the receiving client by the payment client
  • the second signature result is the result obtained by deblinding the first signature result.
  • the signature data is blinded through the payment client, and the currency provider node signs the blinding result, which realizes the protection of the signature data, and the currency provider node cannot associate the signature with the payment client, thus realizing the payment to the customer
  • the protection of terminal information avoids the security problems caused by eavesdroppers obtaining the private information of both parties of the transaction, thereby improving the security of the transaction.
  • Fig. 1 is a system schematic diagram 1 of a transaction method based on blind signature provided by an embodiment of the application;
  • FIG. 2 is a schematic diagram of the second system of the blind signature-based transaction method provided by an embodiment of the application;
  • Fig. 3 is a signaling flowchart 1 of a transaction method based on blind signature provided by an embodiment of the application;
  • FIG. 4 is a signaling flowchart 2 of the blind signature-based transaction method provided by an embodiment of the application.
  • FIG. 5 is a first structural diagram of a blind signature-based transaction device provided by an embodiment of the application.
  • Fig. 6 is a second structural diagram of a transaction device based on blind signature provided by an embodiment of the application.
  • FIG. 7 is a schematic diagram 1 of the hardware structure of a blind signature-based transaction device provided by an embodiment of the application.
  • FIG. 8 is a second schematic diagram of the hardware structure of a blind signature-based transaction device provided by an embodiment of the application.
  • Blind signature is a way to sign a message. It allows the message sender to blindly process the original message, then let the signer sign the blinded message, and finally the message sender performs the process according to the deblinding factor.
  • the deblinding process obtains the signature of the signer on the original message.
  • the deblinding factor is a factor designed for the blinding process, which can eliminate the effect of the blinding process.
  • the blind signature means that the message sender is not allowed to sign A special digital signature technology adopted when the user obtains the specific content of the signed message, the blind signature will be introduced in detail below in conjunction with FIG. 1.
  • Fig. 1 is a system schematic diagram 1 of a transaction method based on blind signature provided by an embodiment of the application.
  • the message sender 101 and the signer 102 are included.
  • the message sender 101 blinds the original message.
  • the blinding process refers to processing the original message according to the blinding factor.
  • it can be a unique password of the message sender 101, or for example, a series of calculation parameters specific to the message sender 101.
  • the embodiment of the present application does not impose special restrictions on the blinding process, and the original message is processed to ensure that others
  • the processing that cannot obtain the original content belongs to the protection scope of this embodiment, and those skilled in the art can understand that the specific process of the blinding processing can be set as required.
  • the message sender 101 sends the blinded message to the signer 102, where the signer 102 signs the received blinded message.
  • the signature means that the signer can only generate it and cannot be forged.
  • a piece of digital string, this piece of digital string is a valid proof of the authenticity of the signer’s signature to the message.
  • the embodiment of this application does not specifically limit the specific way of signing.
  • the signer 102 is in the process of signing because the signed The content of is a blinded message, so the specific content signed by it cannot be obtained, thus ensuring the confidentiality of the signing process.
  • the signer 102 obtains the signature of the blinded message after the signature is completed, and further sends the signature to the message sender 101, where the message sender 101 is also set with a deblinding factor, deblinding factor and blinding
  • the deblinding factor can be the decryption value of the unique password of the message sender 101
  • the deblinding factor can be the inverse process parameter of a series of calculation parameters specific to the message sender.
  • the signature of the original message is obtained, where the content of the signature of the original message is executed by the signer 102, but in the signing process, the signer 102 cannot obtain the specific content of the original message, and because the content signed by the signer 102 is a blinded message, the signer 102 cannot associate the content of its signature with the message sender 101, so the blind signature guarantees the correctness
  • the protection of the original message content also realizes the protection of the identity of the message sender 101.
  • a blind signature means that the person who needs to sign first puts the document to be signed and a piece of carbon paper into a sealed envelope (blind processing), when the document is in the envelope , No one except the person who seals the envelope can open the envelope.
  • the signer signs the envelope, and the content of the signature is signed on the document through carbon paper.
  • the person who needs to sign opens the envelope (deblinding process), and the signed document Take it out, which is the process of blind signing.
  • Non-repudiation Once a signer signs a message, he cannot deny his signature of the message.
  • the embodiment of the application proposes a transaction method based on blind signature.
  • the following describes the transaction method based on the blind signature provided by the embodiment of the application in detail with reference to specific embodiments.
  • Fig. 2 is a second schematic diagram of the system of the blind signature-based transaction method provided by an embodiment of the application. As shown in FIG. 2, it includes: a payment client 201, a payment client 202 and a currency providing node 203.
  • the payment client 201 is the client used by the payer in the transaction
  • the receiver 202 is the receiver of the transaction.
  • the clients used, the payment client 201 and the payment client 202 may be nodes in the blockchain, for example, and the embodiment of the present application does not limit the specific implementation of the payment client 201 and the payment client 202.
  • the blockchain is a special distributed database. Any data can be written to the blockchain, and data can also be read from the blockchain. Any user can use their own terminal equipment to join the blockchain. Becoming one of the nodes, the blockchain has the characteristics of decentralization, trustlessness, and data that cannot be tampered with. When a user joins the blockchain through the payment client 201 or the payment client 202, it becomes a node in the blockchain.
  • the payment client 201 may upload the digital asset to be traded to the blockchain, for example, and may also perform blind processing on transaction-related data, etc.
  • the embodiment of the present application does not make any special mention on this Limited, where the collection client 202 can be used to verify transaction-related data, for example, and can also be used to collect payments for digital assets to be traded, etc.
  • the embodiment of the application does not limit the specific functions of the collection client 202 .
  • a currency providing node 203 is also provided, where the currency providing node 203 is a node in the blockchain, and the currency providing node 203 is used as an intermediate node for the payment client 201 and the payment client 202 to conduct transactions, for example It can be used to store digital assets to be traded by the payment client 201, and can also be used to sign transaction-related data, etc.
  • the embodiment of the present application does not particularly limit the specific implementation of the currency providing node 203.
  • the payment client 201 sends the digital asset to be traded to the currency providing node, and further the payment client 201 sends transaction-related data to the currency providing node 203 for blind signature, and the payment client 201 sends The signature result and transaction-related data are sent to the receiving client.
  • the receiving client and the currency provider node verify according to the signature result and transaction-related data to determine whether the transaction is correct and valid. When the verification is passed, the currency provider node 203 will wait The digital assets of the transaction are sent to the collection client 202 to complete the transaction.
  • the embodiment of the application provides a transaction method based on blind signature, which is combined below Figure 3 describes in further detail.
  • Fig. 3 is a signaling flowchart 1 of the blind signature-based transaction method provided by an embodiment of the application. As shown in Figure 3, the method includes:
  • the payment client performs blinding processing according to the transaction service parameters and the signature data to obtain a blinding result.
  • the transaction service parameters are used to instruct the payment client and the payment client to conduct transactions related to transaction data.
  • the transaction service parameters may include transaction time, and may also include address information of both parties to the transaction.
  • the embodiments of this application do not impose special restrictions on transaction service parameters. All parameters used to indicate the transaction process belong to transaction service parameters. Those skilled in the art can understand that transaction service parameters can be as required Make settings.
  • the signature data is the original data that needs to be signed.
  • the signature data can be, for example, a random number generated by the payment client to identify a transaction, or, for example, can be data generated by the payment client according to preset rules.
  • the embodiment does not particularly limit the signature data.
  • the payment client performs blinding processing according to transaction service parameters and signature data.
  • the blinding processing may be, for example, that the payment client calculates transaction service parameters and signature data according to the blinding factor.
  • the embodiment of the present application does not limit the specific implementation of the blinding processing.
  • the blinding factor has been introduced in the above-mentioned embodiments and will not be repeated here.
  • the specific calculation may be calculated based on a hash function, for example, or may be based on a preset Formulas for calculations, etc.
  • the preset calculations may include, for example, a combination of calculation methods such as addition, subtraction, multiplication, etc.
  • the embodiments of this application do not limit the specific implementation of the calculation during the blinding process. Those skilled in the art can understand that the blinding
  • the specific calculation method of processing can be set as required.
  • the blinding result is obtained after the blinding process, where the blinding result corresponds to the signature data, and no node in the blockchain can obtain the signature data corresponding to the blinding result except for the payment client.
  • the payment client sends a first signature request to the money providing node, where the first signature request carries the blinding result.
  • the payment client sends a first signature request carrying the blinding result to the currency providing node, where the first signature request is used to initiate a request for processing the blinding result to the currency providing node.
  • the first signature request may also carry, for example, a signature algorithm specified by the payment client.
  • the embodiment of the present application does not limit the specific implementation of the first signature request.
  • the money providing node receives a first signature request sent by the payment client, where the first signature request carries a blinding result, and the blinding result is a result obtained by the payment client according to the transaction service parameters and the signature data for blinding processing.
  • the money providing node receives the first signature request sent by the payment client, and signs the blinding result according to the first signature request.
  • the specific implementation of the signature can be, for example, a hash signature, or for example, asymmetric encryption.
  • the embodiments of the present application do not specifically limit the specific implementation of the signature, and those skilled in the art can understand that the specific algorithm of the signature can be selected according to needs.
  • the blinding result is the result of the payment client's blinding processing based on the transaction service parameters and signature data. Therefore, the first signature result obtained by signing the blinding result is actually the signature for the transaction service parameters and signature data. In the signing process, the currency providing node cannot obtain the specific signature data, thereby ensuring the security of the signature data.
  • the payment client receives the first signature result sent by the money providing node, where the first signature result is a result obtained by the money providing node signing the blinding result.
  • the payment client deblinds the first signature result to obtain the second signature result.
  • the payment client receives the first signature result sent by the money providing node, and deblinds the first signature result, where deblinding is the reverse process of the blinding process and can eliminate the blinding process Effect, specifically, the payment client processes the first signature result according to the deblinding factor to obtain the second signature result.
  • the deblinding factor has been introduced in the above-mentioned embodiment, and will not be repeated here. There is no restriction on the specific implementation of blinding.
  • the blinding factor corresponds to the deblinding factor, and only the payment client can obtain the blinding factor and the deblinding factor. Therefore, it can be ensured that the currency providing node cannot obtain the signature data during the signing process.
  • the first signature result is The result obtained by the currency provider node signing the blinding result.
  • the second signature result obtained after the payment client deblinds the first signature result eliminates the blinding effect. Therefore, the second signature result is the direct result of the currency provider node. The result of signing according to transaction service parameters and signature data.
  • the payment client sends the second signature result and the signature data to the payment client.
  • the receiving client sends the second signature result and signature data to the money providing node.
  • the payment client sends the second signature result and the signature data to the receiving client, and the receiving client further sends the second signature result and the signature data to the money providing node, thereby verifying the signature data and the second signature result Is it correct and true and effective.
  • the receiving client may also perform verification according to the second signature result and the signature data. Specifically, the receiving client may decrypt the second signature data according to the public key of the payment client, and determine the decryption result and the signature data. Whether they are consistent, to determine whether the current transaction is valid, and further, to determine whether to perform the current transaction according to the verification result of the currency providing node.
  • the money providing node receives the signature data and the second signature result sent by the receiving client, and completes the transaction after the signature data and the second signature result are verified, where the signature data and the second signature result are sent to the payment client
  • the second signature result is the result of deblinding the first signature result.
  • the currency providing node verifies the transaction according to the signature data sent by the receiving client and the second signature result, where the specific verification method may be, for example, performing reverse process calculation on the second signature result according to the signature algorithm. Determine whether the calculated result is consistent with the signature data.
  • the verification method can also be, for example, judging the signature data and the second verification result according to the preset model to determine whether it conforms to the preset model, where the preset model is obtained from the signature.
  • the second signature result is the result obtained by deblinding the first signature result
  • the first signature result is obtained by signing by the currency providing node
  • the second signature result is essentially the result of providing the currency to the signature data It is obtained by signing, so the currency providing node can realize verification according to the signature data and the second signature result.
  • the receiving client realizes the payment and the transaction is completed.
  • the blind signature-based transaction method provided by the embodiment of the application includes: the payment client performs blind processing according to transaction service parameters and signature data to obtain a blind result.
  • the payment client sends a first signature request to the currency providing node, and the first signature request carries the blinding result.
  • the money providing node receives the first signature request sent by the payment client, signs the blinding result, and obtains the first signature result.
  • the currency providing node sends the first signature result to the payment client.
  • the payment client receives the first signature result sent by the currency providing node.
  • the payment client deblinds the first signature result, obtains the second signature result, and sends the second signature result and the signature data to the payment client.
  • the receiving client sends the second signature result and signature data to the money providing node.
  • the money providing node receives the signature data and the second signature result sent by the receiving client, and completes the transaction after the signature data and the second signature result are verified.
  • the signature data and the second signature result are sent to the receiving client by the payment client
  • the second signature result is the result obtained by deblinding the first signature result.
  • the signature data is blinded through the payment client, and the currency provider node signs the blinding result, which realizes the protection of the signature data, and the currency provider node cannot associate the signature with the payment client, thus realizing the payment to the customer
  • the protection of terminal information avoids the security problems caused by eavesdroppers obtaining the private information of both parties of the transaction, thereby improving the security of the transaction.
  • Figure 4 is the second signaling flowchart of the blind signature-based transaction method provided by an embodiment of the application. As shown in Figure 4. The method includes:
  • the payment client sends digital assets to the currency providing node.
  • the payer needs to pay a certain amount of digital assets to the payee to complete the transaction.
  • the payment client sends the digital assets to the currency providing node, and the currency providing node is used as The intermediate node of the transaction is similar to the existence of a bank.
  • the currency providing node is also a node in the blockchain.
  • S402 The money providing node receives the digital asset sent by the payment client.
  • the currency providing node stores the digital assets of the payment client.
  • the currency provider node also needs to generate a public key and a private key.
  • the private key is randomly generated, and only the currency provider node knows its own private key.
  • the public key is generated based on the private key.
  • the remaining nodes can obtain the public key of the currency providing node, use the public key of the currency providing node to encrypt data, and send the encrypted data to the currency providing node after encryption.
  • the currency providing node can use the private key to decrypt the data, and the public key and the private key can realize the data interaction between the nodes and prevent the data from being obtained by other nodes.
  • the public key and The private key realizes the signature of transaction service parameters and signature data.
  • the payment client sends a second signature request to the money providing node, where the second signature request carries transaction service parameters.
  • the payment client sends a second signature request carrying transaction service parameters to the money providing node.
  • the transaction service parameters have been introduced in the above embodiments and will not be repeated here.
  • the second The signature request is used to instruct the currency provider node to sign transaction service parameters.
  • the second signature request may also carry, for example, a specified signature algorithm or additional conditions of the payment client. The specific implementation of the second signature request in this embodiment of the application No special restrictions.
  • the money providing node receives a second signature request sent by the payment client, where the second signature request carries transaction service parameters.
  • the money providing node signs the transaction service parameters according to the second signature request sent by the payment client, where the specific method of signing may be, for example, signing according to the algorithm specified in the transaction service parameters, or for example, according to a preset algorithm For signing, the embodiment of this application does not specifically limit the specific implementation of the signature.
  • the transaction service parameters can be signed by the currency provider to effectively identify the transaction so that the validity of the transaction can be subsequently verified.
  • the payment client receives a third signature result sent by the money providing node, where the third signature result is a result obtained by the money providing node signing the transaction service parameters.
  • the payment client performs blinding processing according to the third signature result and the signature data to obtain the blinding result.
  • the payment client receives the third signature result sent by the currency providing node, and further, performs a blinding process according to the third signature result and the signature data to obtain the blinding result, where the blinding process refers to according to the blinding factor
  • the signature data is processed, where the blinding factor can be, for example, a random number, or can also be, for example, data generated according to a preset algorithm.
  • the blinding factor is the first randomly generated random number below. The number and the second random number are introduced as examples.
  • the final commitment value can be generated according to the third signature result and the first random number and the second random number, where the final commitment value is used to indicate the generation of the blinding result.
  • the final commitment value can be generated according to the signature data and The final promise value is hashed to obtain the challenge value.
  • the operation of the signature data is added.
  • the challenge value is also used to indicate the generation of the blinding result.
  • the signature data is generated random Number, used to identify a transaction.
  • the blinding result is obtained according to the challenge value and the second random number.
  • the specific implementation of obtaining the final commitment value, the challenge value and the blinding result can be, for example, a combination of various basic operations, or a combination of multiple algorithms.
  • the embodiment of the application does not specifically limit the calculation method. Those skilled in the art can understand that the specific implementation method for calculating the final commitment value, challenge value, and blinding result can be set as required, as long as the signature data can be implemented. Just blind.
  • the blinding result is the result of the blinding process performed by the payment client according to the third signature result and the signature data.
  • the payment client sends a first signature request to the currency providing node, where the first signature request carries the blinding result.
  • S409 is similar to that of S302, and will not be repeated here.
  • the money providing node receives a first signature request sent by the payment client, where the first signature request carries a blinding result, and the blinding result is a result obtained by the payment client according to the transaction service parameters and the signature data.
  • S411 The currency providing node signs the blinding result to obtain the first signature result.
  • S410 and S411 is similar to that of S303 and S304, and will not be repeated here.
  • S412 The currency providing node sends the first signature result to the payment client.
  • the payment client receives the first signature result sent by the money providing node, where the first signature result is a result obtained by the money providing node signing the blinding result.
  • S414 The payment client deblinds the first signature result to obtain the second signature result.
  • S412, S413, and S414 is similar to that of S305, S306, and S307, and will not be repeated here.
  • the payment client sends the second signature result and the signature data to the payment client.
  • the receiving client sends the second signature result and signature data to the currency providing node.
  • S415 and S416 is similar to that of S308 and S309, and will not be repeated here.
  • the money providing node receives the signature data and the second signature result sent by the receiving client, and determines that the signature data received from the receiving client is not in the signature data list.
  • the money providing node stores the signature data in the verified transaction to obtain a list of signature data.
  • the signature data in this embodiment is a random number generated by the payment client, such as It can be 256 bits, which can uniquely identify a transaction. This is only an exemplary description, and the specific number of bits of the signature data is not particularly limited.
  • the money providing node searches according to the signature data and the signature data list sent by the receiving client, and determines whether the signature data sent by the receiving client is in the signature data list. If it exists, it is considered as the receiving client.
  • the transaction corresponding to the sent signature data has been completed, that is, the payment client and the digital assets in this transaction have been paid, thereby effectively avoiding the double-spending problem, that is, the problem of the payment client trying to complete two transactions with one digital asset .
  • S418 The currency providing node uses the second signature result and the signature data as the input of the preset model.
  • a preset model is provided, where the preset model is a model composed of the public key of the currency providing node, the second signature result, the signature data, and the preset parameters, and is used to sign the second signature. The result and the signature correctness of the signature data are verified.
  • the specific design of the preset model corresponds to the processing of the aforementioned signature algorithm.
  • the specific design of the preset model is not particularly limited in the embodiment of this application. Those skilled in the art It can be understood that the design of the preset model can be selected according to actual needs.
  • the preset model is used to verify whether the current second signature result is obtained by the currency providing node signing the signature data and transaction service parameters, where the second signature result is the result obtained by deblinding the first signature result , In essence, it is the result obtained by the currency provider node directly signing the signature data. Therefore, the currency provider node uses the second signature result and the signature data as the input of the preset model. When the signature data and the second signature result are accurate, it can satisfy If the equation relationship of the preset model is determined to be satisfied, the verification is determined to be passed, that is, the currency providing node verifies that the second signature result is obtained by signing according to the transaction service parameters and the signature data.
  • the currency providing node determines that the transaction is true and valid, and pays the digital asset sent by the payer to the payee, thereby completing the transaction.
  • the blind signature-based transaction method provided in the embodiment of the present application includes: a payment client sends digital assets to a currency providing node.
  • the currency provider node receives the digital assets sent by the payment client.
  • the payment client sends a second signature request to the money providing node, and the second signature request carries transaction service parameters.
  • the money providing node receives a second signature request sent by the payment client, and the second signature request carries transaction service parameters.
  • the currency providing node signs the transaction service parameters to obtain the third signature result.
  • the currency providing node sends the third signature result to the payment client.
  • the payment client receives the third signature result sent by the currency providing node.
  • the payment client performs blinding processing according to the third signature result and the signature data to obtain the blinding result.
  • the payment client sends a first signature request to the currency providing node, and the first signature request carries the blinding result.
  • the money providing node receives the first signature request sent by the payment client.
  • the currency providing node signs the blinding result to obtain the first signature result.
  • the currency providing node sends the first signature result to the payment client.
  • the payment client receives the first signature result sent by the currency providing node.
  • the payment client deblinds the first signature result to obtain the second signature result.
  • the payment client sends the second signature result and the signature data to the payment client.
  • the receiving client sends the second signature result and signature data to the money providing node.
  • the money providing node receives the signature data and the second signature result sent by the receiving client, and determines that the signature data received from the receiving client is not in the signature data list.
  • the currency providing node takes the second signature result and the signature data as the input of the preset model.
  • the currency providing node judges whether the preset model satisfies the equation relationship, and if so, confirms that the verification is passed.
  • the currency providing node pays the digital asset to the receiving client.
  • the signature message and transaction service parameters are processed through the payment client to ensure the security of transaction data in the transaction process and realize the identity protection of the payment client.
  • the signature data list is set by the currency provider to verify the signature data. Effectively guarantee the authenticity and validity of the transaction.
  • Fig. 5 is a first structural diagram of a blind signature-based transaction device provided by an embodiment of the application.
  • the blind signature-based transaction device 50 includes: a receiving module 501, a signature module 502, and a transaction module 503.
  • the receiving module 501 is used for the money providing node to receive the first signature request sent by the payment client.
  • the first signature request carries the blinding result.
  • the blinding result is the result obtained by the payment client according to the transaction service parameters and signature data. ;
  • the signature module 502 is used for the currency providing node to sign the blinding result, obtain the first signature result, and send the first signature result to the payment client;
  • the transaction module 503 is used for the money providing node to receive the signature data and the second signature result sent by the receiving client, and complete the transaction after the signature data and the second signature result are verified, where the signature data and the second signature result are payment
  • the second signature result sent by the client to the receiving client is the result of deblinding the first signature result.
  • the receiving module 501 is also used for:
  • the money providing node receives the second signature request sent by the payment client, and the second signature request carries transaction service parameters;
  • the currency providing node signs the transaction service parameters to obtain the third signature result
  • the currency providing node sends the third signature result to the payment client
  • the blinding result is the result of the blinding process performed by the payment client according to the third signature result and the signature data.
  • the receiving module 501 is also used for:
  • the currency providing node determines that the signature data received from the receiving client is not in the signature data list
  • the currency providing node verifies the second signature result and the signature data according to the preset model, and obtains the verified result.
  • the transaction module 503 is specifically used for:
  • the currency providing node takes the second signature result and signature data as the input of the preset model
  • the currency providing node judges whether the preset model satisfies the equation relationship, and if so, confirms that the verification is passed.
  • the receiving module 501 is also used for:
  • the currency provider node receives the digital assets sent by the payment client
  • the transaction module 503 is also used for:
  • the currency providing node pays the digital asset to the receiving client.
  • the device provided in this embodiment can be used to implement the technical solutions of the foregoing method embodiments, and its implementation principles and technical effects are similar, and will not be repeated here in this embodiment.
  • Fig. 6 is a second structural diagram of a blind signature-based transaction device provided by an embodiment of the application.
  • the blind signature-based transaction device 60 includes: a blinding module 601, a sending module 602, a receiving module 603, and a deblinding module 604.
  • the blinding module 601 is used for the payment client to perform blinding processing according to transaction service parameters and signature data to obtain the blinding result;
  • the sending module 602 is used for the payment client to send a first signature request to the money providing node, the first signature request carrying the blinding result;
  • the receiving module 603 is configured to receive the first signature result sent by the money providing node by the payment client, where the first signature result is the result obtained by the money providing node signing the blinding result;
  • the deblinding module 604 is used for the payment client to deblind the first signature result to obtain the second signature result, and send the second signature result and signature data to the payment client.
  • the sending module 602 is also used for:
  • the payment client sends a second signature request to the money providing node, and the second signature request carries transaction service parameters;
  • the payment client receives the third signature result sent by the currency provider node, and the third signature result is the result obtained by the currency provider node signing the transaction service parameters;
  • the blinding module 601 is specifically used for:
  • the payment client performs blinding processing according to the third signature result and the signature data to obtain the blinding result.
  • the sending module 602 is specifically used for:
  • the payment client sends digital assets to the currency providing node.
  • the device provided in this embodiment can be used to implement the technical solutions of the foregoing method embodiments, and its implementation principles and technical effects are similar, and will not be repeated here in this embodiment.
  • FIG. 7 is a schematic diagram 1 of the hardware structure of a blind signature-based transaction device provided by an embodiment of the application.
  • the transaction device 70 based on blind signature of this embodiment includes: a processor 701 and a memory 702; wherein
  • the memory 702 is used to store computer execution instructions
  • the processor 701 is configured to execute computer-executable instructions stored in the memory to implement each step executed by the blind signature-based transaction method in the foregoing embodiment. For details, refer to the related description in the foregoing method embodiment.
  • the memory 702 may be independent or integrated with the processor 701.
  • the blind signature-based transaction device further includes a bus 703 for connecting the memory 702 and the processor 701.
  • FIG. 8 is a second schematic diagram of the hardware structure of a blind signature-based transaction device provided by an embodiment of the application.
  • the blind signature-based transaction device 80 of this embodiment includes: a processor 801 and a memory 802; wherein
  • the memory 802 is used to store computer execution instructions
  • the processor 801 is configured to execute computer-executable instructions stored in the memory, so as to implement each step executed by the blind signature-based transaction method in the foregoing embodiment. For details, refer to the related description in the foregoing method embodiment.
  • the memory 802 may be independent or integrated with the processor 801.
  • the blind signature-based transaction device further includes a bus 803 for connecting the memory 802 and the processor 801.
  • the embodiment of the present application also provides a computer-readable storage medium, and the computer-readable storage medium stores computer-executable instructions.
  • the processor executes the computer-executable instructions
  • the above-mentioned blind signature-based transaction device executes Transaction method based on blind signature.
  • the embodiment of the present application also provides a computer-readable storage medium, and the computer-readable storage medium stores computer-executable instructions.
  • the processor executes the computer-executable instructions
  • the above-mentioned blind signature-based transaction device executes Transaction method based on blind signature.
  • the disclosed device and method may be implemented in other ways.
  • the device embodiments described above are only illustrative.
  • the division of the modules is only a logical function division, and there may be other divisions in actual implementation, for example, multiple modules can be combined or integrated. To another system, or some features can be ignored, or not implemented.
  • the displayed or discussed mutual coupling or direct coupling or communication connection may be indirect coupling or communication connection through some interfaces, devices or modules, and may be in electrical, mechanical or other forms.
  • the above-mentioned integrated modules implemented in the form of software function modules may be stored in a computer readable storage medium.
  • the above-mentioned software function module is stored in a storage medium and includes several instructions to make a computer device (which can be a personal computer, a server, or a network device, etc.) or a processor (English: processor) to execute the various embodiments of the present application Part of the method.
  • processor may be a central processing unit (English: Central Processing Unit, abbreviated: CPU), or other general-purpose processors, digital signal processors (English: Digital Signal Processor, abbreviated: DSP), and application-specific integrated circuits (English: Application Specific Integrated Circuit, referred to as ASIC) etc.
  • the general-purpose processor may be a microprocessor or the processor may also be any conventional processor or the like.
  • the steps of the method disclosed in combination with the invention can be directly embodied as being executed by a hardware processor, or executed by a combination of hardware and software modules in the processor.
  • the memory may include a high-speed RAM memory, and may also include a non-volatile storage NVM, such as at least one disk storage, and may also be a U disk, a mobile hard disk, a read-only memory, a magnetic disk, or an optical disk.
  • NVM non-volatile storage
  • the bus may be an Industry Standard Architecture (ISA) bus, Peripheral Component (PCI) bus, or Extended Industry Standard Architecture (EISA) bus, etc.
  • ISA Industry Standard Architecture
  • PCI Peripheral Component
  • EISA Extended Industry Standard Architecture
  • the bus can be divided into address bus, data bus, control bus, etc.
  • the buses in the drawings of this application are not limited to only one bus or one type of bus.
  • the above-mentioned storage medium can be realized by any type of volatile or non-volatile storage device or their combination, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable Except for programmable read only memory (EPROM), programmable read only memory (PROM), read only memory (ROM), magnetic memory, flash memory, magnetic disks or optical disks.
  • SRAM static random access memory
  • EEPROM electrically erasable programmable read-only memory
  • EPROM erasable except for programmable read only memory
  • PROM programmable read only memory
  • ROM read only memory
  • magnetic memory flash memory
  • flash memory magnetic disks or optical disks.
  • optical disks any available medium that can be accessed by a general-purpose or special-purpose computer.
  • a person of ordinary skill in the art can understand that all or part of the steps in the foregoing method embodiments can be implemented by a program instructing relevant hardware.
  • the aforementioned program can be stored in a computer readable storage medium.
  • the steps including the foregoing method embodiments are executed; and the foregoing storage medium includes: ROM, RAM, magnetic disk, or optical disk and other media that can store program codes.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Marketing (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Computing Systems (AREA)
  • Technology Law (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Software Systems (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

一种基于盲签名的交易方法及装置。该方法包括：支付客户端根据交易服务参数和签名数据进行盲化处理，得到盲化结果。支付客户端向货币提供节点发送第一签名请求。货币提供节点接收支付客户端发送的第一签名请求，对盲化结果进行签名，得到第一签名结果。货币提供节点将第一签名结果发送给支付客户端。支付客户端接收货币提供节点发送的第一签名结果。支付客户端对第一签名结果去盲化，得到第二签名结果，将第二签名结果和签名数据发送给收款客户端。收款客户端将第二签名结果和签名数据发送给货币提供节点。货币提供节点在签名数据和第二签名结果验证通过后完成交易，从而提高了交易的安全性。

Description

基于盲签名的交易方法及装置
本申请要求于2019年03月22日提交中国专利局、申请号为2019102235663、申请名称为“基于盲签名的交易方法及装置”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请实施例涉及计算机技术，尤其涉及一种基于盲签名的交易方法及装置。
背景技术
区块链是一种去中介化的数据库，在基于区块链进行交易的过程中，其中区块链为交易双方提供了公开可见、抗篡改、去中心化的系统。
现有技术在基于区块链进行交易时，交易双方将包含有交易双方地址信息的交易相关信息上传至区块链，区块链中的节点根据交易相关信息对交易进行验证，在验证通过后控制交易完成。
然而，窃听者根据地址信息能够获取到交易双方的私密信息，从而导致交易过程存在安全问题。
发明内容
本申请实施例提供一种基于盲签名的交易方法及装置，以克服在区块链交易过程中交易双方存在的安全问题。
第一方面，本申请实施例提供一种基于盲签名的交易方法，包括：
货币提供节点接收支付客户端发送的第一签名请求，所述第一签名请求携带盲化结果，所述盲化结果是所述支付客户端根据交易服务参数和签名数据进行盲化处理得到的结果；
所述货币提供节点对所述盲化结果进行签名，得到第一签名结果，并将所述第一签名结果发送给所述支付客户端；
所述货币提供节点接收收款客户端发送的签名数据和第二签名结果，并在所述签名数据和所述第二签名结果验证通过后完成交易，其中，所述签名数据和所述第二签名结果为所述支付客户端发送给所述收款客户端的，所述第二签名结果为对所述第一签名结果进行去盲化得到的结果。
在一种可能的设计中，所述货币提供节点接收支付客户端发送的第一签名请求之前，还包括：
所述货币提供节点接收所述支付客户端发送的第二签名请求，所述第二签名请求携带所述交易服务参数；
所述货币提供节点对所述交易服务参数进行签名，得到第三签名结果；
所述货币提供节点向所述支付客户端发送所述第三签名结果；
对应的，所述盲化结果是所述支付客户端根据所述第三签名结果和所述签名数据 进行盲化处理得到的结果。
在一种可能的设计中，所述货币提供节点在所述签名数据和所述第二签名结果验证通过后完成交易之前，还包括：
所述货币提供节点确定从所述收款客户端接收到的签名数据不在签名数据列表中；
所述货币提供节点根据预设模型对所述第二签名结果和所述签名数据进行验证，得到验证通过的结果。
在一种可能的设计中，所述货币提供节点根据预设模型对所述第二签名结果和所述签名数据进行验证，得到验证通过的结果，包括：
所述货币提供节点将所述第二签名结果和所述签名数据作为所述预设模型的输入；
所述货币提供节点判断所述预设模型是否满足等式关系，若是，则确定验证通过。
在一种可能的设计中，所述货币提供节点接收支付客户端发送的第一签名请求之前，还包括：
所述货币提供节点接收所述支付客户端发送的数字资产；
所述货币提供节点在所述签名数据和所述第二签名结果验证通过后完成交易，包括：
所述货币提供节点将所述数字资产支付给所述收款客户端。
第二方面，本申请实施例提供一种基于盲签名的交易方法，包括：
支付客户端根据交易服务参数和签名数据进行盲化处理，得到盲化结果；
所述支付客户端向货币提供节点发送第一签名请求，所述第一签名请求携带盲化结果；
所述支付客户端接收所述货币提供节点发送的第一签名结果，其中第一签名结果为所述货币提供节点对所述盲化结果进行签名得到的结果；
所述支付客户端对所述第一签名结果去盲化，得到第二签名结果，并将所述第二签名结果和所述签名数据发送给收款客户端。
在一种可能的设计中，在所述支付客户端根据交易服务参数和签名数据进行盲化处理，得到盲化结果之前，还包括：
所述支付客户端向所述货币提供节点发送第二签名请求，所述第二签名请求携带所述交易服务参数；
所述支付客户端接收所述货币提供节点发送的第三签名结果，所述第三签名结果为所述货币提供节点对所述交易服务参数进行签名得到的结果；
所述支付客户端根据交易服务参数和签名数据进行盲化处理，得到盲化结果，包括：
所述支付客户端根据所述第三签名结果和所述签名数据进行盲化处理，得到盲化结果。
在一种可能的设计中，所述支付客户端根据交易服务参数和签名数据进行盲化处理，得到盲化结果之前，还包括：
所述支付客户端向所述货币提供节点发送数字资产。
第三方面，本申请实施例提供一种基于盲签名的交易装置，包括：
接收模块，用于货币提供节点接收支付客户端发送的第一签名请求，所述第一签 名请求携带盲化结果，所述盲化结果是所述支付客户端根据交易服务参数和签名数据进行盲化处理得到的结果；
签名模块，用于所述货币提供节点对所述盲化结果进行签名，得到第一签名结果，并将所述第一签名结果发送给所述支付客户端；
交易模块，用于所述货币提供节点接收收款客户端发送的签名数据和第二签名结果，并在所述签名数据和所述第二签名结果验证通过后完成交易，其中，所述签名数据和所述第二签名结果为所述支付客户端发送给所述收款客户端的，所述第二签名结果为对所述第一签名结果进行去盲化得到的结果。
在一种可能的设计中，所述接收模块，还用于：
所述货币提供节点接收所述支付客户端发送的第二签名请求，所述第二签名请求携带所述交易服务参数；
所述货币提供节点对所述交易服务参数进行签名，得到第三签名结果；
所述货币提供节点向所述支付客户端发送所述第三签名结果；
对应的，所述盲化结果是所述支付客户端根据所述第三签名结果和所述签名数据进行盲化处理得到的结果。
在一种可能的设计中，所述接收模块，还用于：
所述货币提供节点确定从所述收款客户端接收到的签名数据不在签名数据列表中；
所述货币提供节点根据预设模型对所述第二签名结果和所述签名数据进行验证，得到验证通过的结果。
在一种可能的设计中，所述交易模块具体用于：
所述货币提供节点将所述第二签名结果和所述签名数据作为所述预设模型的输入；
所述货币提供节点判断所述预设模型是否满足等式关系，若是，则确定验证通过。
在一种可能的设计中，所述接收模块，还用于：
所述货币提供节点接收所述支付客户端发送的数字资产；
所述交易模块，还用于：
所述货币提供节点将所述数字资产支付给所述收款客户端。
第四方面，本申请实施例提供一种基于盲签名的交易装置，包括：
盲化模块，用于支付客户端根据交易服务参数和签名数据进行盲化处理，得到盲化结果；
发送模块，用于所述支付客户端向货币提供节点发送第一签名请求，所述第一签名请求携带盲化结果；
接收模块，用于所述支付客户端接收所述货币提供节点发送的第一签名结果，其中第一签名结果为所述货币提供节点对所述盲化结果进行签名得到的结果；
去盲化模块，用于所述支付客户端对所述第一签名结果去盲化，得到第二签名结果，并将所述第二签名结果和所述签名数据发送给收款客户端。
在一种可能的设计中，所述发送模块，还用于：
所述支付客户端向所述货币提供节点发送第二签名请求，所述第二签名请求携带所述交易服务参数；
所述支付客户端接收所述货币提供节点发送的第三签名结果，所述第三签名结果为所述货币提供节点对所述交易服务参数进行签名得到的结果；
所述盲化模块，具体用于：
所述支付客户端根据所述第三签名结果和所述签名数据进行盲化处理，得到盲化结果。
在一种可能的设计中，所述发送模块具体用于：
所述支付客户端向所述货币提供节点发送数字资产。
第五方面，本申请实施例提供一种基于盲签名的交易设备，包括：
存储器，用于存储程序；
处理器，用于执行所述存储器存储的所述程序，当所述程序被执行时，所述处理器用于执行如上第一方面以及第一方面各种可能的设计中任一所述的方法。
第六方面，本申请实施例提供一种基于盲签名的交易设备，包括：
存储器，用于存储程序；
处理器，用于执行所述存储器存储的所述程序，当所述程序被执行时，所述处理器用于执行如上第二方面以及第二方面各种可能的设计中任一所述的方法。
第七方面，本申请实施例提供一种计算机可读存储介质，包括指令，当其在计算机上运行时，使得计算机执行如上第一方面以及第一方面各种可能的设计中任一所述的方法。
第八方面，本申请实施例提供一种计算机可读存储介质，包括指令，当其在计算机上运行时，使得计算机执行如上第一方面以及第一方面各种可能的设计中任一所述的方法。
本申请实施例提供一种基于盲签名的交易方法及装置，该方法包括：支付客户端根据交易服务参数和签名数据进行盲化处理，得到盲化结果。支付客户端向货币提供节点发送第一签名请求，第一签名请求携带盲化结果。货币提供节点接收支付客户端发送的第一签名请求，对盲化结果进行签名，得到第一签名结果。货币提供节点将第一签名结果发送给支付客户端。支付客户端接收货币提供节点发送的第一签名结果。支付客户端对第一签名结果去盲化，得到第二签名结果，将第二签名结果和签名数据发送给收款客户端。收款客户端将第二签名结果和签名数据发送给货币提供节点。货币提供节点接收收款客户端发送的签名数据和第二签名结果，并在签名数据和第二签名结果验证通过后完成交易，其中，签名数据和第二签名结果为支付客户端发送给收款客户端的，第二签名结果为对第一签名结果进行去盲化得到的结果。通过支付客户端对签名数据进行盲化处理，货币提供节点对盲化结果进行签名，实现了对签名数据的保护，并且货币提供节点无法将签名与支付客户端对应起来，从而实现了对支付客户端信息的保护，避免了窃听者获取交易双方私密信息而导致的安全问题，从而提高了交易的安全性。
附图说明
图1为本申请实施例提供的基于盲签名的交易方法的系统示意图一；
图2为本申请实施例提供的基于盲签名的交易方法的系统示意图二；
图3为本申请实施例提供的基于盲签名的交易方法的信令流程图一；
图4为本申请实施例提供的基于盲签名的交易方法的信令流程图二；
图5为本申请实施例提供的基于盲签名的交易装置的结构示意图一；
图6为本申请实施例提供的基于盲签名的交易装置的结构示意图二；
图7为本申请实施例提供的基于盲签名的交易设备的硬件结构示意图一；
图8为本申请实施例提供的基于盲签名的交易设备的硬件结构示意图二。
具体实施方式
首先对本申请所涉及的区块链的概念进行解释。
盲签名是一种对消息进行签名的方式，其允许消息发送者先对原始消息进行盲化处理，而后让签名者对盲化处理后的消息进行签名，最后消息发送者根据去盲化因子进行去盲化处理，得到签名者关于原始消息的签名，其中去盲化因子是针对盲化处理所设计的因子，能够实现对盲化处理的效果的消除，盲签名就是消息发送者在不让签名者获取所签名的消息的具体内容的情况下所采取的一种特殊的数字签名技术，下面结合图1对盲签名进行详细介绍。
图1为本申请实施例提供的基于盲签名的交易方法的系统示意图一。如图1所示，包括消息发送者101以及签名者102，其中消息发送者101对原始消息进行盲化处理，具体的，盲化处理是指根据盲化因子对原始消息进行处理，盲化因子例如可以为消息发送者101特有的密码，还例如可以为消息发送者101特定的一系列计算参数等，本申请实施例对盲化处理不做特别限制，凡是对原始消息进行处理从而保证其他人无法获取原始内容的处理均属于本实施例的保护范围，本领域技术人员可以理解，其中盲化处理的具体过程可以根据需要进行设定。
进一步地，消息发送者101将盲化处理的消息发送给签名者102，其中签名者102对接收到的盲化处理的消息进行签名，具体的，签名是指签名者才能产生的并且无法伪造的一段数字串，这段数字串对签名者对消息进行签名的真实性的一个有效证明，本申请实施例对签名的具体方式不做特别限制，其中签名者102在签名的过程中，因为所签名的内容是盲化处理的消息，因此无法获取其所签名的具体内容，从而保证了签名过程的保密性。
具体的，签名者102签名完成后得到对盲化处理的消息的签名，进一步将该签名发送给消息发送者101，其中消息发送者101还设置有去盲化因子，去盲化因子与盲化因子是相对应的，例如去盲化因子可以为消息发送者101特有密码的解密值，还例如去盲化因子可以为消息发送者特定的一系列计算参数的反过程参数等，本申请实施例对去盲化处理不做也别限制，凡是对盲化处理的效果进行消除的处理均属于本申请实施例的保护范围。
在本实施例中，对盲化处理的消息的签名进行去盲化处理之后得到对原始消息的签名，其中对原始消息的签名内容是由签名者102所执行的，但是在签名过程中签名者102无法获取原始消息的而具体内容，并且因为签名者102所签名的内容是盲化处理的消息，因此签名者102无法将其签名的内容与消息发送者101对应起来，因此盲签名保证了对原始消息内容的保护，同时实现了对消息发送者101身份的保护。
关于盲签名，此处给出一个举例性的直观说明：盲签名就是需要签名的人先将待签名的文件以及一张复写纸放进密封的信封里(盲化处理)，当文件在信封中时，除密封的人之外任何人都无法打开该信封，签名者在信封上进行签名，签名的内容透过复写纸签到文件上，需要签名的人打开信封(去盲化处理)，将签名的文件拿出来，即为盲签名的过程。
盲签名应该具有以下的性质：
不可伪造性。除了签名者之外，任何第三方无法以签名者的名义生成有效的盲签名。
不可抵赖性。签名者一旦对某个消息进行签名，无法否认自己对消息的签名。
盲性。签名者虽然对某个消息进行了签名，但签名者无法获取消息的具体内容。
不可跟踪性。原始消息的签名公开后，签名者不能确定自己何时对这条消息进行了签名。
本申请实施例基于盲签名提出了一种交易方法，下面结合具体的实施例对本申请实施例提供的基于盲签名的交易方法进行详细介绍。首先结合图2进行介绍。
图2为本申请实施例提供的基于盲签名的交易方法的系统示意图二。如图2所示，包括：支付客户端201、收款客户端202以及货币提供节点203。
具体的，在一次交易进行时存在交易双方，分别为支付方以及收款方，其中，支付客户端201为交易中支付方所使用的客户端，收款客户端202为交易中收款方所使用的客户端，支付客户端201以及收款客户端202例如可以为区块链中的节点，本申请实施例对支付客户端201以及收款客户端202的具体实现方式不做限制。
其中，区块链是一种特殊的分布式数据库，任何数据都可以写入区块链，也可以从区块链中读取数据，其中任何用户都可以使用自己的终端设备加入区块链，成为其中的一个节点，区块链具有去中心化、去信任化以及数据无法篡改的特点。当用户通过支付客户端201或者收款客户端202加入至区块链时，即成为区块链中的节点。
进一步地，在进行交易的过程中，支付客户端201例如可以将待交易的数字资产上传至区块链，还例如可以对交易相关数据进行盲化处理等，本申请实施例对此不做特别限定，其中收款客户端202例如可以用于对交易相关数据进行验证，还例如可以用于对待交易的数字资产进行收款等，本申请实施例对收款客户端202的具体功能不做限制。
在本实施例中，还设置有货币提供节点203，其中货币提供节点203为区块链中的节点，货币提供节点203用作支付客户端201和收款客户端202进行交易的中间节点，例如可以用于对支付客户端201待交易的数字资产进行存储，还例如可以用于对交易相关数据进行签名等，本申请实施例对货币提供节点203的具体实现方式不做特别限制。
具体的，在需要进行交易时，支付客户端201将待交易的数字资产发送至货币提供节点，进一步地支付客户端201将交易相关数据发送至货币提供节点203进行盲签名，支付客户端201将签名结果以及交易相关数据发送至收款客户端，收款客户端以及货币提供节点根据签名结果以及交易相关数据进行验证，从而判断此次交易是否正确有效，在验证通过时货币提供节点203将待交易的数字资产发送至收款客户端202 从而完成交易。
基于现有技术在进行交易的过程中，支付客户端201以及收款客户端202的信息私密信息可能暴露而存在安全隐患的问题，本申请实施例提供一种基于盲签名的交易方法，下面结合图3进行进一步地详细介绍。
图3为本申请实施例提供的基于盲签名的交易方法的信令流程图一。如图3所示，该方法包括：
S301、支付客户端根据交易服务参数和签名数据进行盲化处理，得到盲化结果。
其中，交易服务参数用于指示支付客户端和收款客户端进行交易的过程中相关交易数据，例如交易服务参数可以包括交易时间，还例如可以包括交易双方的地址信息等，还例如可以用于对签名过程中的算法进行指定等，本申请实施例对交易服务参数不做特别限制，凡是用于指示交易过程的参数均属于交易服务参数，本领域技术人员可以理解，交易服务参数可以根据需要进行设定。
进一步地，签名数据为需要进行签名的原始数据，其中签名数据例如可以为支付客户端生成的用于标识一次交易的随机数，还例如可以为支付客户端根据预设规则生成的数据，本申请实施例对签名数据不做特别限制。
在本实施例中，支付客户端根据交易服务参数和签名数据进行盲化处理，具体的，盲化处理例如可以为支付客户端根据盲化因子对交易服务参数以及签名数据进行计算，还例如可以为支付客户端根据货币提供节点对交易服务参数处理的结果以及盲化因子对签名数据进行计算，本申请实施例对盲化处理的具体实现方式不做限制。
其中，盲化因子在上述实施例中以及进行了介绍，此处不再赘述，在进行盲化处理的过程中，具体的计算例如可以为根据哈希函数进行计算，还例如可以为根据预设公式进行计算等，预设计算例如可以包括加法、减法、乘法等计算方法的组合等，本申请实施例对盲化处理时计算的具体实现方式不做限制，本领域技术人员可以理解，盲化处理的具体计算方式可以根据需要进行设定。
进一步地，盲化处理后得到盲化结果，其中盲化结果对应有签名数据，除支付客户端之外，区块链中的任何节点均无法获取盲化结果对应的签名数据。
S302、支付客户端向货币提供节点发送第一签名请求，第一签名请求携带盲化结果。
具体的，支付客户端将携带有盲化结果的第一签名请求发送至货币提供节点，其中第一签名请求用于向货币提供节点发起对盲化结果进行处理的请求，可选地，第一签名请求还例如可以携带有支付客户端规定的签名算法等，本申请实施例对第一签名请求的具体实现方式不做限制。
S303、货币提供节点接收支付客户端发送的第一签名请求，第一签名请求携带盲化结果，盲化结果是支付客户端根据交易服务参数和签名数据进行盲化处理得到的结果。
S304、货币提供节点对盲化结果进行签名，得到第一签名结果。
进一步地，货币提供节点接收支付客户端发送的第一签名请求，并根据第一签名请求对盲化结果进行签名，其中签名的具体实现方式例如可以为哈希签名，还例如可以为非对称加密签名等，本申请实施例对签名的具体实现方式不做特别限制，本领域 技术人员可以理解，签名的具体算法可以根据需要进行选择。
其中，盲化结果是支付客户端根据交易服务参数和签名数据进行盲化处理得到的结果，因此对盲化结果进行签名得到的第一签名结果实际上是针对交易服务参数和签名数据进行的签名，在签名过程中，货币提供节点无法获取具体的签名数据，从而保证的签名数据的安全性。
S305、货币提供节点将第一签名结果发送给支付客户端。
S306、支付客户端接收货币提供节点发送的第一签名结果，其中第一签名结果为货币提供节点对盲化结果进行签名得到的结果。
S307、支付客户端对第一签名结果去盲化，得到第二签名结果。
在本实施例中，支付客户端接收货币提供节点发送的第一签名结果，并对第一签名结果进行去盲化，其中去盲化是针对盲化处理的反过程，能够消除盲化处理的效果，具体的，支付客户端根据去盲因子对第一签名结果进行处理得到第二签名结果，去盲因子在上述实施例中已经进行了介绍，此处不再赘述，本申请实施例对去盲化的具体实现方式不做限制。
具体的，盲化因子与去盲因子相对应，并且只有支付客户端能够获取盲化因子以及去盲因子，因此能够保证签名过程中货币提供节点无法获取签名数据，进一步地，第一签名结果为货币提供节点对盲化结果进行签名得到的结果，支付客户端对第一签名结果进行去盲化之后得到的第二签名结果消除了盲化的作用，因此第二签名结果即为货币提供节点直接根据交易服务参数以及签名数据进行签名得到的结果。
通过进行盲签名，能够有效实现货币提供节点对交易服务参数和签名数据进行签名，并且在签名过程中无法获取签名数据，也无法将第二签名结果与支付客户端对应起来。
S308、支付客户端将第二签名结果和签名数据发送给收款客户端。
S309、收款客户端将第二签名结果和签名数据发送给货币提供节点。
进一步地，支付客户端将第二签名结果以及签名数据发送给收款客户端，收款客户端进一步将第二签名结果以及签名数据发送至货币提供节点，从而验证该签名数据以及第二签名结果是否正确以及真实有效。
可选地，收款客户端还可以根据第二签名结果以及签名数据进行验证，具体的，收款客户端例如可以根据支付客户端的公钥对第二签名数据进行解密，判断解密结果与签名数据是否一致，从而判断当前的交易是否有效，进一步地，再根据货币提供节点的验证结果判断是否要进行当前交易。
S310、货币提供节点接收收款客户端发送的签名数据和第二签名结果，并在签名数据和第二签名结果验证通过后完成交易，其中，签名数据和第二签名结果为支付客户端发送给收款客户端的，第二签名结果为对第一签名结果进行去盲化得到的结果。
在本实施例中，货币提供节点根据收款客户端发送的签名数据和第二签名结果对交易进行验证，其中验证的具体方式例如可以为根据签名的算法对第二签名结果进行反过程计算，判断得到的计算结果与签名数据是否一致，其中验证的方式还例如可以为根据预设模型对签名数据和第二验证结果进行判断，判断其是否符合预设模型，其中预设模型为根据签名得到的模型，本申请实施例对验证的具体实现方式不做特别限 定。
具体的，其中第二签名结果为对第一签名结果进行去盲化得到的结果，而第一签名结果为货币提供节点进行签名得到的，因此第二签名结果实质上为货币提供结果对签名数据进行签名得到的，因此货币提供节点能够根据签名数据和第二签名结果实现验证，当验证通过后收款客户端实现收款，交易完成。
本申请实施例提供的基于盲签名的交易方法，包括：支付客户端根据交易服务参数和签名数据进行盲化处理，得到盲化结果。支付客户端向货币提供节点发送第一签名请求，第一签名请求携带盲化结果。货币提供节点接收支付客户端发送的第一签名请求，对盲化结果进行签名，得到第一签名结果。货币提供节点将第一签名结果发送给支付客户端。支付客户端接收货币提供节点发送的第一签名结果。支付客户端对第一签名结果去盲化，得到第二签名结果，将第二签名结果和签名数据发送给收款客户端。收款客户端将第二签名结果和签名数据发送给货币提供节点。货币提供节点接收收款客户端发送的签名数据和第二签名结果，并在签名数据和第二签名结果验证通过后完成交易，其中，签名数据和第二签名结果为支付客户端发送给收款客户端的，第二签名结果为对第一签名结果进行去盲化得到的结果。通过支付客户端对签名数据进行盲化处理，货币提供节点对盲化结果进行签名，实现了对签名数据的保护，并且货币提供节点无法将签名与支付客户端对应起来，从而实现了对支付客户端信息的保护，避免了窃听者获取交易双方私密信息而导致的安全问题，从而提高了交易的安全性。
在上述实施例的基础上，下面结合图4对本申请实施例提供的基于盲签名的交易方法进行进一步地详细介绍。
图4为本申请实施例提供的基于盲签名的交易方法的信令流程图二。如图4所示。该方法包括：
S401、支付客户端向货币提供节点发送数字资产。
具体的，在进行交易的过程是需要支付方将一定数额的数字资产支付给收款方从而完成交易，在本实施例中，支付客户端将数字资产发送给货币提供节点，货币提供节点用作交易的中间节点，类似于银行的存在，在本申请实施例中货币提供节点同样是区块链中的节点。
S402、货币提供节点接收支付客户端发送的数字资产。
在本实施例中，货币提供节点对支付客户端的数字资产进行存储。
可选地，货币提供节点还需要生成公钥以及私钥，其中私钥为随机生成的，并且只有货币提供节点知道自己的私钥，其中公钥为根据私钥生成的，区块链中的其余节点能够获取到货币提供节点的公钥，利用货币提供节点的公钥对数据进行加密，加密之后将加密的数据发送给货币提供节点。
进一步地，货币提供节点利用私钥能够实现对数据的解密，利用公钥和私钥能实现节点之间的数据交互并且防止被其他节点获取到数据，在本申请实施例中，利用公钥和私钥实现对交易服务参数以及签名数据的签名。
S403、支付客户端向货币提供节点发送第二签名请求，第二签名请求携带交易服务参数。
在本实施例中，支付客户端向货币提供节点发送携带有交易服务参数的第二签名 请求，其中交易服务参数在上述实施例中已经进行了介绍，此处不再赘述，进一步地，第二签名请求用于指示货币提供节点对交易服务参数进行签名处理，其中第二签名请求还例如可以携带指定的签名算法或者支付客户端的额外条件等，本申请实施例对第二签名请求的具体实现方式不做特别限制。
S404、货币提供节点接收支付客户端发送的第二签名请求，第二签名请求携带交易服务参数。
S405、货币提供节点对交易服务参数进行签名，得到第三签名结果。
进一步地，货币提供节点根据支付客户端发送的第二签名请求对交易服务参数进行签名，其中签名的具体方式例如可以为根据交易服务参数中规定的算法进行签名，还例如可以为根据预设算法进行签名，本申请实施例对签名的具体实现方式不做特别限制。
通过货币提供接待对交易服务参数进行签名处理，可以有效的对此次交易进行标识，以便后续验证交易的有效性。
S406、货币提供节点向支付客户端发送第三签名结果。
S407、支付客户端接收货币提供节点发送的第三签名结果，第三签名结果为货币提供节点对交易服务参数进行签名得到的结果。
S408、支付客户端根据第三签名结果和签名数据进行盲化处理，得到盲化结果。
在本实施例中，支付客户端接收货币提供节点发送的第三签名结果，进一步地，根据第三签名结果以及签名数据进行盲化处理得到盲化结果，其中盲化处理是指根据盲化因子对签名数据进行处理，其中盲化因子例如可以为随机数，还例如可以为根据预设算法生成的数据，本申请实施例对此不做限制，下面以盲化因子为随机生成的第一随机数以及第二随机数为例进行介绍。
在进行盲化处理时，例如可以根据第三签名结果以及第一随机数和第二随机数生成最终承诺值，其中最终承诺值用于指示生成盲化结果，进一步地，例如可以根据签名数据以及最终承诺值进行哈希运算，得到挑战值，在计算挑战值的时候加入了对签名数据的运算，挑战值同样用于指示生成盲化结果，在本申请实施例中，签名数据为生成的随机数，用于标识一次交易。
其次根据挑战值以及第二随机数得到盲化结果，其中得到最终承诺值、挑战值以及盲化结果的具体实现方式例如可以为各种基础运算的组合，还例如可以为多种算法的结合，本申请实施例对其计算的方式不做特别限制，本领域技术人员可以理解，计算最终承诺值、挑战值以及盲化结果的具体实现方式可以根据需要进行设定，只要能够实现对签名数据进行盲化即可。
对应的，在本申请实施例中，盲化结果是支付客户端根据第三签名结果和签名数据进行盲化处理得到的结果。
S409、支付客户端向货币提供节点发送第一签名请求，第一签名请求携带盲化结果。
具体的，S409的实现方式与S302类似，此处不再赘述。
S410、货币提供节点接收支付客户端发送的第一签名请求，第一签名请求携带盲化结果，盲化结果是支付客户端根据交易服务参数和签名数据进行盲化处理得到的结 果。
S411、货币提供节点对盲化结果进行签名，得到第一签名结果。
具体的，S410、S411的实现方式与S303、S304类似，此处不再赘述。
S412、货币提供节点将第一签名结果发送给支付客户端。
S413、支付客户端接收货币提供节点发送的第一签名结果，其中第一签名结果为货币提供节点对盲化结果进行签名得到的结果。
S414、支付客户端对第一签名结果去盲化，得到第二签名结果。
具体的，S412、S413、S414的实现方式与S305、S306、S307类似，此处不再赘述。
S415、支付客户端将第二签名结果和签名数据发送给收款客户端。
S416、收款客户端将第二签名结果和签名数据发送给货币提供节点。
具体的，S415、S416的实现方式与S308、S309类似，此处不再赘述。
S417、货币提供节点接收收款客户端发送的签名数据和第二签名结果，确定从收款客户端接收到的签名数据不在签名数据列表中。
在本申请实施例中，货币提供节点对验证完成的交易中的签名数据进行存储，得到签名数据列表，进一步地，本实施例中的签名数据为支付客户端生成的随机数，该随机数例如可以为256位，能够唯一的标识一次交易，此处仅为示例性说明，对签名数据的具体位数不做特别限制。
进一步地，货币提供节点根据收款客户端发送的签名数据以及签名数据列表进行查找，判断收款客户端发送的签名数据时是否存在签名数据列表中，若存在，则认为此次收款客户端发送的签名数据对应的交易已经完成，即支付客户端以及将此次交易中的数字资产支出了，从而有效避免了双花问题，即支付客户端试图用一份数字资产完成两份交易的问题。
可选地，若经过判断，确定从收款客户端接收到的签名数据不在签名数据列表中，则能够判定当前签名数据所对应的交易尚未发生，即当前的交易是有效的，从而能够执行后续的签名验证。
S418、货币提供节点将第二签名结果和签名数据作为预设模型的输入。
S419、货币提供节点判断预设模型满足等式关系时确定验证通过。
进一步地，在本申请实施例中，设置有预设模型，其中预设模型为根据货币提供节点的公钥、第二签名结果、签名数据以及预设参数组成的模型，用于对第二签名结果以及签名数据的签名正确性进行验证，其中预设模型的具体设计是与前述的签名算法的处理相对应的，本申请实施例对预设模型的具体设计不做特别限制，本领域技术人员可以理解，预设模型的设计可以根据实际需要进行选择。
具体的，预设模型用于验证当前的第二签名结果是否是货币提供节点对签名数据以及交易服务参数进行签名得到的，其中第二签名结果为对第一签名结果进行去盲化得到的结果，本质上即为货币提供节点直接对签名数据进行签名得到的结果，因此货币提供节点将第二签名结果和签名数据作为预设模型的输入，当签名数据与第二签名结果准确时，能够满足预设模型的等式关系，若确定满足等式关系，则确定验证通过，即货币提供节点验证该第二签名结果是自己根据交易服务参数以及签名数据进行签名 得到的。
S420、货币提供节点将数字资产支付给收款客户端。
进一步地，在验证通过之后，货币提供节点确定此次交易真实有效，将支付方发送的数字资产支付给收款方，从而完成此次交易。
本申请实施例提供的基于盲签名的交易方法，包括：支付客户端向货币提供节点发送数字资产。货币提供节点接收支付客户端发送的数字资产。支付客户端向货币提供节点发送第二签名请求，第二签名请求携带交易服务参数。货币提供节点接收支付客户端发送的第二签名请求，第二签名请求携带交易服务参数。货币提供节点对交易服务参数进行签名，得到第三签名结果。货币提供节点向支付客户端发送第三签名结果。支付客户端接收货币提供节点发送的第三签名结果。支付客户端根据第三签名结果和签名数据进行盲化处理，得到盲化结果。支付客户端向货币提供节点发送第一签名请求，第一签名请求携带盲化结果。货币提供节点接收支付客户端发送的第一签名请求。货币提供节点对盲化结果进行签名，得到第一签名结果。货币提供节点将第一签名结果发送给支付客户端。支付客户端接收货币提供节点发送的第一签名结果。支付客户端对第一签名结果去盲化，得到第二签名结果。支付客户端将第二签名结果和签名数据发送给收款客户端。收款客户端将第二签名结果和签名数据发送给货币提供节点。货币提供节点接收收款客户端发送的签名数据和第二签名结果，确定从收款客户端接收到的签名数据不在签名数据列表中。货币提供节点将第二签名结果和签名数据作为预设模型的输入。货币提供节点判断预设模型是否满足等式关系，若是，则确定验证通过。货币提供节点将数字资产支付给收款客户端。通过支付客户端对签名消息和交易服务参数进行处理，保证了交易过程中交易数据的安全性，以及实现了对支付客户端的身份保护，并且通过货币提供节点设置签名数据列表对签名数据进行验证，有效保证了交易的真实性以及有效性。
图5为本申请实施例提供的基于盲签名的交易装置的结构示意图一。如图5所示，该基于盲签名的交易装置50包括：接收模块501、签名模块502以及交易模块503。
接收模块501，用于货币提供节点接收支付客户端发送的第一签名请求，第一签名请求携带盲化结果，盲化结果是支付客户端根据交易服务参数和签名数据进行盲化处理得到的结果；
签名模块502，用于货币提供节点对盲化结果进行签名，得到第一签名结果，并将第一签名结果发送给支付客户端；
交易模块503，用于货币提供节点接收收款客户端发送的签名数据和第二签名结果，并在签名数据和第二签名结果验证通过后完成交易，其中，签名数据和第二签名结果为支付客户端发送给收款客户端的，第二签名结果为对第一签名结果进行去盲化得到的结果。
可选地，接收模块501，还用于：
货币提供节点接收支付客户端发送的第二签名请求，第二签名请求携带交易服务参数；
货币提供节点对交易服务参数进行签名，得到第三签名结果；
货币提供节点向支付客户端发送第三签名结果；
对应的，盲化结果是支付客户端根据第三签名结果和签名数据进行盲化处理得到的结果。
可选地，接收模块501，还用于：
货币提供节点确定从收款客户端接收到的签名数据不在签名数据列表中；
货币提供节点根据预设模型对第二签名结果和签名数据进行验证，得到验证通过的结果。
可选地，交易模块503具体用于：
货币提供节点将第二签名结果和签名数据作为预设模型的输入；
货币提供节点判断预设模型是否满足等式关系，若是，则确定验证通过。
可选地，接收模块501，还用于：
货币提供节点接收支付客户端发送的数字资产；
交易模块503，还用于：
货币提供节点将数字资产支付给收款客户端。
本实施例提供的装置，可用于执行上述方法实施例的技术方案，其实现原理和技术效果类似，本实施例此处不再赘述。
图6为本申请实施例提供的基于盲签名的交易装置的结构示意图二。如图6所示，该基于盲签名的交易装置60包括：盲化模块601、发送模块602、接收模块603以及去盲化模块604。
盲化模块601，用于支付客户端根据交易服务参数和签名数据进行盲化处理，得到盲化结果；
发送模块602，用于支付客户端向货币提供节点发送第一签名请求，第一签名请求携带盲化结果；
接收模块603，用于支付客户端接收货币提供节点发送的第一签名结果，其中第一签名结果为货币提供节点对盲化结果进行签名得到的结果；
去盲化模块604，用于支付客户端对第一签名结果去盲化，得到第二签名结果，并将第二签名结果和签名数据发送给收款客户端。
发送模块602，还用于：
支付客户端向货币提供节点发送第二签名请求，第二签名请求携带交易服务参数；
支付客户端接收货币提供节点发送的第三签名结果，第三签名结果为货币提供节点对交易服务参数进行签名得到的结果；
盲化模块601，具体用于：
支付客户端根据第三签名结果和签名数据进行盲化处理，得到盲化结果。
发送模块602具体用于：
支付客户端向货币提供节点发送数字资产。
本实施例提供的装置，可用于执行上述方法实施例的技术方案，其实现原理和技术效果类似，本实施例此处不再赘述。
图7为本申请实施例提供的基于盲签名的交易设备的硬件结构示意图一。如图7所示，本实施例的基于盲签名的交易设备70包括：处理器701以及存储器702；其中
存储器702，用于存储计算机执行指令；
处理器701，用于执行存储器存储的计算机执行指令，以实现上述实施例中基于盲签名的交易方法所执行的各个步骤。具体可以参见前述方法实施例中的相关描述。
可选地，存储器702既可以是独立的，也可以跟处理器701集成在一起。
当存储器702独立设置时，该基于盲签名的交易设备还包括总线703，用于连接所述存储器702和处理器701。
图8为本申请实施例提供的基于盲签名的交易设备的硬件结构示意图二。如图8所示，本实施例的基于盲签名的交易设备80包括：处理器801以及存储器802；其中
存储器802，用于存储计算机执行指令；
处理器801，用于执行存储器存储的计算机执行指令，以实现上述实施例中基于盲签名的交易方法所执行的各个步骤。具体可以参见前述方法实施例中的相关描述。
可选地，存储器802既可以是独立的，也可以跟处理器801集成在一起。
当存储器802独立设置时，该基于盲签名的交易设备还包括总线803，用于连接所述存储器802和处理器801。
本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，当处理器执行所述计算机执行指令时，实现如上基于盲签名的交易设备所执行的基于盲签名的交易方法。
本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，当处理器执行所述计算机执行指令时，实现如上基于盲签名的交易设备所执行的基于盲签名的交易方法。
在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。例如，以上所描述的设备实施例仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个模块可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或模块的间接耦合或通信连接，可以是电性，机械或其它的形式。
上述以软件功能模块的形式实现的集成的模块，可以存储在一个计算机可读取存储介质中。上述软件功能模块存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(英文：processor)执行本申请各个实施例所述方法的部分步骤。
应理解，上述处理器可以是中央处理单元(英文：Central Processing Unit，简称：CPU)，还可以是其他通用处理器、数字信号处理器(英文：Digital Signal Processor，简称：DSP)、专用集成电路(英文：Application Specific Integrated Circuit，简称：ASIC)等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合发明所公开的方法的步骤可以直接体现为硬件处理器执行完成，或者用处理器中的硬件及软件模块组合执行完成。
存储器可能包含高速RAM存储器，也可能还包括非易失性存储NVM，例如至少一个磁盘存储器，还可以为U盘、移动硬盘、只读存储器、磁盘或光盘等。
总线可以是工业标准体系结构(Industry Standard Architecture，ISA)总线、外部设备互连(Peripheral Component，PCI)总线或扩展工业标准体系结构(Extended  Industry Standard Architecture，EISA)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，本申请附图中的总线并不限定仅有一根总线或一种类型的总线。
上述存储介质可以是由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。存储介质可以是通用或专用计算机能够存取的任何可用介质。
本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。
最后应说明的是：以上各实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述各实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的范围。

Claims (20)

  1. 一种基于盲签名的交易方法，其特征在于，应用于区块链，所述方法包括：
    货币提供节点接收支付客户端发送的第一签名请求，所述第一签名请求携带盲化结果，所述盲化结果是所述支付客户端根据交易服务参数和签名数据进行盲化处理得到的结果；
    所述货币提供节点对所述盲化结果进行签名，得到第一签名结果，并将所述第一签名结果发送给所述支付客户端；
    所述货币提供节点接收收款客户端发送的签名数据和第二签名结果，并在所述签名数据和所述第二签名结果验证通过后完成交易，其中，所述签名数据和所述第二签名结果为所述支付客户端发送给所述收款客户端的，所述第二签名结果为对所述第一签名结果进行去盲化得到的结果。
  2. 根据权利要求1所述的方法，其特征在于，所述货币提供节点接收支付客户端发送的第一签名请求之前，还包括：
    所述货币提供节点接收所述支付客户端发送的第二签名请求，所述第二签名请求携带所述交易服务参数；
    所述货币提供节点对所述交易服务参数进行签名，得到第三签名结果；
    所述货币提供节点向所述支付客户端发送所述第三签名结果；
    对应的，所述盲化结果是所述支付客户端根据所述第三签名结果和所述签名数据进行盲化处理得到的结果。
  3. 根据权利要求1所述的方法，其特征在于，所述货币提供节点在所述签名数据和所述第二签名结果验证通过后完成交易之前，还包括：
    所述货币提供节点确定从所述收款客户端接收到的签名数据不在签名数据列表中；
    所述货币提供节点根据预设模型对所述第二签名结果和所述签名数据进行验证，得到验证通过的结果。
  4. 根据权利要求3所述的方法，其特征在于，所述货币提供节点根据预设模型对所述第二签名结果和所述签名数据进行验证，得到验证通过的结果，包括：
    所述货币提供节点将所述第二签名结果和所述签名数据作为所述预设模型的输入；
    所述货币提供节点判断所述预设模型是否满足等式关系，若是，则确定验证通过。
  5. 根据权利要求1至4任一项所述的方法，其特征在于，所述货币提供节点接收支付客户端发送的第一签名请求之前，还包括：
    所述货币提供节点接收所述支付客户端发送的数字资产；
    所述货币提供节点在所述签名数据和所述第二签名结果验证通过后完成交易，包括：
    所述货币提供节点将所述数字资产支付给所述收款客户端。
  6. 一种基于盲签名的交易方法，其特征在于，应用于区块链，所述方法包括：
    支付客户端根据交易服务参数和签名数据进行盲化处理，得到盲化结果；
    所述支付客户端向货币提供节点发送第一签名请求，所述第一签名请求携带盲化结果；
    所述支付客户端接收所述货币提供节点发送的第一签名结果，其中第一签名结果为所述货币提供节点对所述盲化结果进行签名得到的结果；
    所述支付客户端对所述第一签名结果去盲化，得到第二签名结果，并将所述第二签名结果和所述签名数据发送给收款客户端。
  7. 根据权利要求6所述的方法，其特征在于，在所述支付客户端根据交易服务参 数和签名数据进行盲化处理，得到盲化结果之前，还包括：
    所述支付客户端向所述货币提供节点发送第二签名请求，所述第二签名请求携带所述交易服务参数；
    所述支付客户端接收所述货币提供节点发送的第三签名结果，所述第三签名结果为所述货币提供节点对所述交易服务参数进行签名得到的结果；
    所述支付客户端根据交易服务参数和签名数据进行盲化处理，得到盲化结果，包括：
    所述支付客户端根据所述第三签名结果和所述签名数据进行盲化处理，得到盲化结果。
  8. 根据权利要求6或7所述的方法，其特征在于，所述支付客户端根据交易服务参数和签名数据进行盲化处理，得到盲化结果之前，还包括：
    所述支付客户端向所述货币提供节点发送数字资产。
  9. 一种基于盲签名的交易装置，其特征在于，应用于区块链，包括：
    接收模块，用于货币提供节点接收支付客户端发送的第一签名请求，所述第一签名请求携带盲化结果，所述盲化结果是所述支付客户端根据交易服务参数和签名数据进行盲化处理得到的结果；
    签名模块，用于所述货币提供节点对所述盲化结果进行签名，得到第一签名结果，并将所述第一签名结果发送给所述支付客户端；
    交易模块，用于所述货币提供节点接收收款客户端发送的签名数据和第二签名结果，并在所述签名数据和所述第二签名结果验证通过后完成交易，其中，所述签名数据和所述第二签名结果为所述支付客户端发送给所述收款客户端的，所述第二签名结果为对所述第一签名结果进行去盲化得到的结果。
  10. 根据权利要求9所述的装置，其特征在于，所述接收模块，还用于：
    所述货币提供节点接收所述支付客户端发送的第二签名请求，所述第二签名请求携带所述交易服务参数；
    所述货币提供节点对所述交易服务参数进行签名，得到第三签名结果；
    所述货币提供节点向所述支付客户端发送所述第三签名结果；
    对应的，所述盲化结果是所述支付客户端根据所述第三签名结果和所述签名数据进行盲化处理得到的结果。
  11. 根据权利要求9所述的装置，其特征在于，所述接收模块，还用于：
    所述货币提供节点确定从所述收款客户端接收到的签名数据不在签名数据列表中；
    所述货币提供节点根据预设模型对所述第二签名结果和所述签名数据进行验证，得到验证通过的结果。
  12. 根据权利要求11所述的装置，其特征在于，所述交易模块具体用于：
    所述货币提供节点将所述第二签名结果和所述签名数据作为所述预设模型的输入；
    所述货币提供节点判断所述预设模型是否满足等式关系，若是，则确定验证通过。
  13. 根据权利要求9至12任一项所述的装置，其特征在于，所述接收模块，还用于：
    所述货币提供节点接收所述支付客户端发送的数字资产；
    所述交易模块，还用于：
    所述货币提供节点将所述数字资产支付给所述收款客户端。
  14. 一种基于盲签名的交易装置，其特征在于，应用于区块链，包括：
    盲化模块，用于支付客户端根据交易服务参数和签名数据进行盲化处理，得到盲化结果；
    发送模块，用于所述支付客户端向货币提供节点发送第一签名请求，所述第一签名请求携带盲化结果；
    接收模块，用于所述支付客户端接收所述货币提供节点发送的第一签名结果，其中第一签名结果为所述货币提供节点对所述盲化结果进行签名得到的结果；
    去盲化模块，用于所述支付客户端对所述第一签名结果去盲化，得到第二签名结果，并将所述第二签名结果和所述签名数据发送给收款客户端。
  15. 根据权利要求14所述的装置，其特征在于，所述发送模块，还用于：
    所述支付客户端向所述货币提供节点发送第二签名请求，所述第二签名请求携带所述交易服务参数；
    所述支付客户端接收所述货币提供节点发送的第三签名结果，所述第三签名结果为所述货币提供节点对所述交易服务参数进行签名得到的结果；
    所述盲化模块，具体用于：
    所述支付客户端根据所述第三签名结果和所述签名数据进行盲化处理，得到盲化结果。
  16. 根据权利要求14或15所述的装置，其特征在于，所述发送模块具体用于：
    所述支付客户端向所述货币提供节点发送数字资产。
  17. 一种基于盲签名的交易设备，其特征在于，包括：
    存储器，用于存储程序；
    处理器，用于执行所述存储器存储的所述程序，当所述程序被执行时，所述处理器用于执行如权利要求1至5中任一所述的方法。
  18. 一种基于盲签名的交易设备，其特征在于，包括：
    存储器，用于存储程序；
    处理器，用于执行所述存储器存储的所述程序，当所述程序被执行时，所述处理器用于执行如权利要求6至8中任一所述的方法。
  19. 一种计算机可读存储介质，其特征在于，包括指令，当其在计算机上运行时，使得计算机执行如权利要求1至5中任一所述的方法。
  20. 一种计算机可读存储介质，其特征在于，包括指令，当其在计算机上运行时，使得计算机执行如权利要求6至8中任一所述的方法。
PCT/CN2020/070109 2019-03-22 2020-01-02 基于盲签名的交易方法及装置 WO2020192236A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP20777894.5A EP3893178B1 (en) 2019-03-22 2020-01-02 Blind signature-based transaction method and device
US17/370,742 US20210334809A1 (en) 2019-03-22 2021-07-08 Transaction method and apparatus based on blind signature

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201910223566.3 2019-03-22
CN201910223566.3A CN109961288B (zh) 2019-03-22 2019-03-22 基于盲签名的交易方法及装置

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/370,742 Continuation US20210334809A1 (en) 2019-03-22 2021-07-08 Transaction method and apparatus based on blind signature

Publications (1)

Publication Number Publication Date
WO2020192236A1 true WO2020192236A1 (zh) 2020-10-01

Family

ID=67024803

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/070109 WO2020192236A1 (zh) 2019-03-22 2020-01-02 基于盲签名的交易方法及装置

Country Status (4)

Country Link
US (1) US20210334809A1 (zh)
EP (1) EP3893178B1 (zh)
CN (1) CN109961288B (zh)
WO (1) WO2020192236A1 (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112734411A (zh) * 2021-01-12 2021-04-30 杭州趣链科技有限公司 基于区块链的交易方法、装置、设备及存储介质
CN116566623B (zh) * 2023-07-05 2023-09-22 北京天润基业科技发展股份有限公司 一种获取匿名数字证书的方法、系统及电子设备
CN117040766B (zh) * 2023-10-08 2024-01-30 腾讯科技（深圳）有限公司 基于区块链的数据处理方法、装置、设备及可读存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160358165A1 (en) * 2015-06-08 2016-12-08 Blockstream Corporation Cryptographically concealing amounts transacted on a ledger while preserving a network's ability to verify the transaction
CN106296138A (zh) * 2016-08-09 2017-01-04 西安电子科技大学 基于部分盲签名技术的比特币支付系统及其方法
CN109359483A (zh) * 2018-10-19 2019-02-19 东北大学秦皇岛分校 一种基于区块链的用户隐私匿名保护方法
CN109447602A (zh) * 2018-10-16 2019-03-08 北京航空航天大学 一种保护隐私的多中心协同分布式数字货币混币方法

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10812274B2 (en) * 2015-05-07 2020-10-20 Blockstream Corporation Transferring ledger assets between blockchains via pegged sidechains
CN105681045B (zh) * 2016-01-14 2019-05-17 北京航空航天大学 盲签名方法和盲签名系统
CN106534089A (zh) * 2016-10-25 2017-03-22 江苏通付盾科技有限公司 一种身份认证方法及装置
CN108109257A (zh) * 2018-01-05 2018-06-01 杭州电子科技大学 一种基于区块链的匿名电子投票方法
CN110719172B (zh) * 2018-07-13 2021-08-10 北京京东尚科信息技术有限公司 区块链系统中的签名方法、签名系统以及相关设备
CN109389498A (zh) * 2018-09-18 2019-02-26 上海诚频信息科技合伙企业(有限合伙) 区块链用户身份管理方法、系统、设备及存储介质
CN109409890B (zh) * 2018-11-13 2020-12-25 华瓴(南京)信息技术有限公司 一种基于区块链的电力交易系统及方法
KR102307483B1 (ko) * 2019-05-28 2021-09-29 한양대학교 산학협력단 순차 결합을 지원하는 전방향 안전 서명 방법 및 그 장치
CN110378690B (zh) * 2019-06-13 2022-05-27 北京航空航天大学 一种基于匿名安全支付通道的交易方法及装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160358165A1 (en) * 2015-06-08 2016-12-08 Blockstream Corporation Cryptographically concealing amounts transacted on a ledger while preserving a network's ability to verify the transaction
CN106296138A (zh) * 2016-08-09 2017-01-04 西安电子科技大学 基于部分盲签名技术的比特币支付系统及其方法
CN109447602A (zh) * 2018-10-16 2019-03-08 北京航空航天大学 一种保护隐私的多中心协同分布式数字货币混币方法
CN109359483A (zh) * 2018-10-19 2019-02-19 东北大学秦皇岛分校 一种基于区块链的用户隐私匿名保护方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3893178A4

Also Published As

Publication number Publication date
EP3893178B1 (en) 2024-02-07
EP3893178A4 (en) 2022-08-31
US20210334809A1 (en) 2021-10-28
EP3893178A1 (en) 2021-10-13
CN109961288A (zh) 2019-07-02
CN109961288B (zh) 2022-04-26

Similar Documents

Publication Publication Date Title
US11588637B2 (en) Methods for secure cryptogram generation
US11809608B2 (en) Methods and systems for using digital signatures to create trusted digital asset transfers
EP3607728B1 (en) Methods and devices for protecting sensitive data of transaction activity based on smart contract in blockchain
CN108764874B (zh) 基于区块链的匿名转账方法、系统及存储介质
CN108418689B (zh) 一种适合区块链隐私保护的零知识证明方法和介质
US11108566B2 (en) Methods and systems for using digital signatures to create trusted digital asset transfers
US20210334809A1 (en) Transaction method and apparatus based on blind signature
CN110612547A (zh) 一种用于信息保护的系统和方法
CN117579281A (zh) 用于使用区块链的所有权验证的方法和系统
US20150356523A1 (en) Decentralized identity verification systems and methods
WO2020181822A1 (zh) 加密数据一致性校验方法、装置、计算机设备及存储介质
CN111815322B (zh) 一种基于以太坊的具备可选隐私服务的分布式支付方法
GB2549118A (en) Electronic payment system using identity-based public key cryptography
CN109447791B (zh) 一种基于区块链的资金交易方法及装置
CN111160909B (zh) 区块链供应链交易隐藏静态监管系统及方法
US20230103038A1 (en) Method for directly transferring electronic coin data sets between terminals, payment system, currency system and monitoring unit
WO2019212829A1 (en) Techniques for performing secure operations
CN109523382A (zh) 独立共识区块链的方法
US12021987B2 (en) Methods for secure cryptogram generation
EP4379631A1 (en) Digital wallet device and dual offline transaction method thereof
CN116992470B (zh) 合作授权协议书签署方法、装置、计算机设备及存储介质
US20240161071A1 (en) Fast blockchain payment method and system
CN116094726A (zh) 一种基于格公钥密码的部分盲签名方法及系统
US20040162790A1 (en) Method and apparatus for identifying the role of an institution in a electronic financial transaction
CN115412256A (zh) 基于区块链的身份认证方法及装置、存储介质、终端设备

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20777894

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2020777894

Country of ref document: EP

Effective date: 20210707

NENP Non-entry into the national phase

Ref country code: DE