WO2022016886A1 - 交易验证的方法、装置 - Google Patents

交易验证的方法、装置 Download PDF

Info

Publication number
WO2022016886A1
WO2022016886A1 PCT/CN2021/080336 CN2021080336W WO2022016886A1 WO 2022016886 A1 WO2022016886 A1 WO 2022016886A1 CN 2021080336 W CN2021080336 W CN 2021080336W WO 2022016886 A1 WO2022016886 A1 WO 2022016886A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction
certificate
chain
sub
verification
Prior art date
Application number
PCT/CN2021/080336
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 EP21847389.0A priority Critical patent/EP4184406A4/en
Publication of WO2022016886A1 publication Critical patent/WO2022016886A1/zh
Priority to US18/156,786 priority patent/US20230177505A1/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/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • 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/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
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • 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/3823—Payment protocols; Details thereof insuring higher security of transaction combining multiple encryption tools for 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/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
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
    • 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

Definitions

  • the embodiments of the present application relate to the field of computer technology, and in particular, to a transaction verification method.
  • Digital currency is generally issued by the central bank of the country.
  • the industry In order to achieve high-performance, high-availability, and high-performance digital currency, the industry generally adopts blockchain and distributed ledger technology or a centralized financial account system based on the existing banking system.
  • blockchain and distributed ledger technology have many advantages, such as the natural immutability of data and distributed consistency, there are still many shortcomings: blockchain technology is still in the development stage, and the current performance may not be enough to support the large-scale digital currency.
  • the transaction pressure brought by large-scale application Therefore, based on the existing centralized banking system architecture solution is the preferred implementation solution, but this solution still has performance bottlenecks in transaction verification.
  • the coin string certificate of digital currency consists of the original coin string and several transaction sub-chains.
  • new transaction sub-chains are continuously added to the end of the coin string certificate, and after each transaction, a digital number is generated for the overall data of the coin string certificate. Sign and verify the validity of digital signatures.
  • the existing technology can effectively realize the functions of online and offline transactions of digital currency, and solve the legality and security problems of currency string certificates.
  • the embodiments of the present application provide a transaction verification method and device, which are applied in the field of computer technology and solve the following problems:
  • Soft Wallet A client-side wallet application implemented on an electronic device that executes in the rich execution environment REE.
  • Hard wallet The wallet business logic and security module implemented on TEE and SE combined with secure hardware features on electronic devices.
  • Applet An application developed and used in SE using the Java Card framework.
  • Issuer The back-end service of the digital currency issuer, responsible for the verification, synchronization, audit, etc. of the digital currency.
  • Original currency string an immutable data structure used to represent the value of digital currency, with a serial number as a unique identifier, carrying information such as currency issuer and amount.
  • Institutional signature used to prove the legitimacy of the original currency string, which is generated by digitally signing the original currency string with the private key of the digital currency issuer.
  • Transaction sub-chain It is appended to the original currency string certificate when two users conduct a transaction, and is used to record the value transfer of a payment behavior, including transaction amount and other information.
  • Token string certificate It is composed of the original coin string and several transaction sub-chains, and the legality is guaranteed by iterative digital signatures.
  • Pre-order transaction A certain transaction sub-chain on the same currency string certificate appends the previous currency string certificate data.
  • the transaction signature appended at the end of the currency string certificate is used to prove the legitimacy of the transaction sub-chain and the previous transaction, which is generated by the private key of the payer.
  • Dual offline transaction When both parties of the digital currency transaction are offline, only the transaction generated by passing the currency string certificate through the terminal device, the transaction will add a new transaction sub-chain at the end of the original currency string certificate to mark the transaction amount, and the transaction at the end will be completed.
  • the amount of the subchain represents the value of the new token string certificate.
  • Serial number As the unique identification of the original currency string, it is consistent with the concept of serial number of banknotes.
  • Coin string synchronization As the user uses digital currency, a large number of small currency strings will gradually accumulate in the user's hard wallet. At this time, the performance of the hard wallet will be affected. Therefore, the user and the issuer need to be synchronized.
  • the small-value coin string is integrated into a full-value coin string and re-issued to the wallet, or deposited into your own bank account.
  • an embodiment of the present application provides a transaction verification method.
  • the method is applied to a first electronic device including a security element SE, a trusted execution environment TEE, and a rich execution environment REE.
  • the method includes: the REE Send a first transaction request message to the TEE, where the first transaction request message includes the transaction type of the transaction; the TEE executes first business logic according to the transaction type to obtain a first verification instruction, the first verification instruction including the digital signature to be verified; the TEE sends the first verification instruction to the SE; the SE verifies the legitimacy of the transaction according to the digital signature to be verified to obtain a first verification result, and converts the The first verification result is sent to the TEE; the TEE sends a first transaction response message to the REE, and the first transaction response message includes the first verification result; the REE is in the first verification result When it is indicated that the verification is successful, a second transaction request message is sent to the second electronic device according to the identifier of the recipient of the transaction, where the identifier of the recipient is used
  • the user After negotiating the payee address, the user initiates a payment operation on the REE side soft wallet, and sends a payment request message to the TEE.
  • the above-mentioned first transaction request message is a payment request.
  • TEE After TEE receives the payment request message, it executes the first business logic, namely the payment business logic, such as basic verification such as transaction times and transaction limit, and sends the first verification instruction to SE. SE will verify the validity of the payment transaction according to the digital signature. The result is returned to the TEE for storage.
  • the user after negotiating the address of the payee, the user initiates a payment operation on the REE side soft wallet, and generates a payment instruction that interacts with the SE, and the SE executes the payment business logic and saves the token string certificate.
  • the SE in the electronic device is an independent operating environment with hardware isolation, the storage space and computing performance are limited.
  • the present application transfers the first business logic and data storage to the TEE side for implementation, and the SE side retains transaction legitimacy verification. , under the premise of ensuring security, make full use of end-side performance and significantly improve user experience.
  • the method further includes that the TEE stores at least one candidate data credential.
  • the TEE executing the first business logic according to the transaction type includes the TEE executing the first business logic according to the transaction type and the at least one candidate data credential.
  • the method further includes that the data certificate is a coin string certificate, and the coin string certificate includes an original coin string or an original coin string and at least one transaction sub-chain, and the digital signature is defined in the The transaction signature appended at the end of the coin string certificate is used to indicate the legitimacy of the transaction sub-chain, the original coin string includes the original coin string amount, the certificate of the issuer, and the signature of the issuer, and the transaction sub-chain includes and the transaction The digital signature of the subchain corresponding to the subchain.
  • the data certificate is a coin string certificate
  • the coin string certificate includes an original coin string or an original coin string and at least one transaction sub-chain
  • the digital signature is defined in the The transaction signature appended at the end of the coin string certificate is used to indicate the legitimacy of the transaction sub-chain
  • the original coin string includes the original coin string amount, the certificate of the issuer, and the signature of the issuer
  • the transaction sub-chain includes and the transaction The digital signature of the subchain corresponding to the subchain.
  • the digital signature in each transaction sub-chain is obtained by digesting the data of the entire coin string certificate, that is, each time a digital signature is generated, an overall signature of all the preceding transaction data is required.
  • Replacing the overall signature scheme with a chain signature scheme reduces redundant digest calculations in the process of generating digital signatures for coin string certificates and verifying digital signatures, improving the performance of terminal-side coin-string certificate generation and verification, and improving terminal-side user experience , while ensuring the legitimacy and integrity of the overall certificate.
  • the first transaction request message further includes the transaction amount of the transaction.
  • the TEE executes the first business logic according to the transaction type and the data voucher of the at least one candidate, and the TEE selects the data from the at least one candidate according to the transaction type and the transaction amount.
  • the currency string certificate to be verified is selected from the currency string certificate; the TEE performs basic verification on the currency string certificate to be verified, and the basic verification includes the verification of transaction times or transaction limit;
  • the digital signature of the sub-chain of the last transaction sub-chain of the coin-string voucher, generating the first verification instruction, and the digital signature of the sub-chain of the last transaction sub-chain of the coin-string voucher that has passed the basic verification is the Verified digital signature, the first verification instruction includes the sub-chain digital signature of the last transaction sub-chain of the coin string certificate that passes the basic verification and the transaction amount.
  • the TEE selects a currency string certificate to be verified from the at least one candidate currency string certificate according to the transaction type and the transaction amount.
  • the TEE can store all the currency string certificates stored in the TEE. , select at least one currency string certificate starting from a large amount of currency string certificate; you can also select a currency string certificate with the closest balance and transaction amount in the currency string certificate saved by TEE according to the transaction amount; you can also save the currency string certificate in TEE Screen out the currency string certificate whose balance is greater than or equal to the transaction amount from the string certificate, and then select at least one currency string certificate according to a certain algorithm; you can also limit the selection of a certain issuer, and preferentially select a single minimum balance that meets the transaction amount requirements.
  • the basic verification performed by the TEE on the token string certificate to be verified may include verifying whether the transaction amount, wallet limit, transaction times, transaction limit, etc. are legal. Verifying the transaction amount may include verifying whether the balance of the coin string certificate meets the transaction amount requirements.
  • the balance of the token string certificate can be saved in the TEE.
  • Wallet limit, transaction times, transaction limit, etc. can be preset on TEE and verified by TEE; or wallet limit, transaction times, transaction limit, etc. can also be preset on SE, and then read from SE to TEE, and then in Verify on TEE. Taking the number of transactions as an example, it can be determined whether the number of transactions is within the preset limit by judging the number of transaction sub-chains or the length of the token string certificate. It can be understood that the foregoing basic verification is only an example, and the present application does not limit the basic verification.
  • the TEE extracts the sub-chain digital signature of the last transaction sub-chain of the coin string certificate that has passed the basic verification, and generates the first verification instruction.
  • the digital signature of the sub-chain of the last transaction sub-chain of the coin string certificate is the digital signature to be verified
  • the first verification instruction includes the digital signature of the sub-chain of the last transaction sub-chain of the coin string certificate that has passed the basic verification and the transaction amount
  • the TEE sends the first verification instruction to the SE.
  • the TEE does not need to send the first verification instruction to the SE.
  • the TEE does not need to generate a new transaction sub-chain by the SE, such as reading the total balance of the current wallet, or when it receives a new currency string certificate for the first time and needs to be verified, it does not need to send the first transaction. Verify instruction to SE.
  • the coin string certificate that has passed the basic verification includes a serial number, and the serial number is a unique identifier of the coin string certificate that has passed the basic verification;
  • the SE is based on the The digital signature to be verified to verify the legality of the transaction to obtain the first verification result includes: the SE generating transaction information according to the transaction amount in the first verification instruction; the SE The stored reference digital signature is compared with the sub-chain digital signature of the last transaction sub-chain in the first verification instruction.
  • the SE When the locally stored reference digital signature is compared with the last transaction in the first verification instruction When the sub-chain digital signatures of the sub-chain are consistent, the SE generates a digital signature corresponding to the transaction according to the transaction information, the sub-chain digital signature of the last transaction sub-chain, and the private key stored locally by the SE; The SE generates a transaction sub-chain corresponding to the transaction according to the digital signature corresponding to the transaction and the transaction information, and the sub-chain digital signature in the transaction sub-chain corresponding to the transaction is the a digital signature corresponding to the transaction; the SE generates a first verification result including the transaction sub-chain corresponding to the transaction. It can be understood that the SE can store the digital signature corresponding to the transaction locally.
  • the first verification instruction will include the number of the last transaction sub-chain of each currency string certificate in the at least one currency string certificate.
  • Signature after receiving the first verification instruction, the SE will compare the subchain digital signature of each last transaction subchain in the first verification instruction with the reference digital signature stored locally by the SE according to the serial number; when the SE When the locally stored reference digital signature is consistent with the sub-chain digital signature of the last transaction sub-chain, the SE is based on the transaction information, the sub-chain digital signature of the last transaction sub-chain and the private key stored locally by the SE.
  • a digital signature corresponding to the transaction is generated. It can be understood that each time the signatures are compared and consistent, a digital signature corresponding to the transaction will be generated, and the SE will generate a transaction sub-chain corresponding to the transaction according to the digital signature corresponding to the transaction and the transaction information.
  • the transaction initiator initiates a 5-yuan transfer transaction. If the TEE selects five 1-yuan currency string certificates locally, the TEE will transfer the last transaction of the five 1-yuan currency string certificates.
  • the sub-chain digital signature of the sub-chain is sent to the SE. After the SE receives it, the sub-chain digital signature of the last transaction sub-chain of the five 1-yuan coin string certificates from the TEE is respectively compared with the sub-chain digital signature stored locally according to the serial number. The signature information is compared, and each time the comparison is consistent, a digital signature corresponding to the transaction and a transaction sub-chain corresponding to the transaction are generated.
  • SE will generate 5 digital signatures corresponding to the transaction and 5 transaction sub-chains corresponding to the transaction.
  • the first verification result will include the five transaction sub-chains corresponding to the transaction.
  • the SE generates the transaction information part in the new transaction sub-chain according to the transaction amount, the unique identifier of the payee's identity, and the unique identifier of the transaction.
  • the TEE saves the first verification result; the TEE updates the transaction sub-chain corresponding to the transaction to the coin string certificate that has passed the basic verification according to the serial number .
  • the method further includes the first electronic device synchronizing the updated coin string credential that has passed the basic verification to a server.
  • the timing of the synchronization of the currency string certificate may be manually triggered by the user, or automatically triggered when the number of transactions reaches the upper limit, etc., which is not limited in this application.
  • the first electronic device may also upload other information related to the coin string voucher, such as the coin string balance, transaction flow, etc. synchronously.
  • the method further includes the first electronic device receiving a confirmation message from the second electronic device to complete the transaction. After receiving the confirmation message, the first electronic device determines that when the amount of the coin string voucher is used up, a deletion flag is marked on the coin string voucher. After the coin string certificate is synchronized to the server, if the coin string certificate is marked with a deletion identifier, the server deletes the coin string certificate.
  • a second aspect provides a transaction verification method, wherein the method is applied to a second electronic device including a security element SE, a trusted execution environment TEE, and a rich execution environment REE, and the method includes: the REE receiving A second transaction request message from the first electronic device, and the second transaction request message is sent to the TEE, where the second transaction request message includes at least one data voucher; the TEE according to the at least one data voucher Execute the second business logic to obtain a second verification instruction, the second verification instruction includes the digital signature to be verified; the TEE sends the second verification instruction to the SE; the SE according to the to-be-verified digital signature The signature verifies the legality of the at least one data certificate to obtain a second verification result, and sends the second verification result to the TEE, the second verification result indicating whether the legality of the at least one data certificate is verified Passed; the TEE receives the second verification result from the SE, saves the data certificate that has passed the verification, and sends a second transaction response message to the REE, where the second transaction
  • SE In the electronic equipment, SE is an independent operating environment with hardware isolation, and the storage space and computing performance are limited.
  • the second business logic and data storage are transferred to the TEE side for implementation, and the SE side retains the data certificate for legality verification , under the premise of ensuring security, make full use of end-side performance and significantly improve user experience.
  • the data certificate includes a coin string certificate
  • the coin string certificate includes an original coin string or an original coin string and at least one transaction sub-chain
  • the original coin string includes the amount of the original coin string
  • the transaction sub-chain includes the sub-chain digital signature corresponding to the transaction sub-chain.
  • the digital signature in each transaction sub-chain is obtained by digesting the data of the entire coin string certificate, that is, each time a digital signature is generated, an overall signature of all the preceding transaction data is required.
  • Replacing the overall signature scheme with a chain signature scheme reduces redundant digest calculations in the process of generating digital signatures for coin string certificates and verifying digital signatures, improving the performance of terminal-side coin-string certificate generation and verification, and improving terminal-side user experience , while ensuring the legitimacy and integrity of the overall certificate.
  • the coin string certificate includes a serial number, and the serial number is a unique identifier of the coin string certificate.
  • the second business logic includes the verification of the institutional signature of the original coin string or the verification of the previous transaction of the last transaction sub-chain of the coin string certificate.
  • coin string verification logic can be performed in TEE, including the institutional signature verification of the original coin string and the sub-chain digital signature verification of other transaction sub-chains except the last transaction sub-chain.
  • the TEE can also perform amount verification, which includes verifying whether the sum of the amount and the transaction amount of the last transaction sub-chain of each currency string certificate in at least one currency string certificate is equal.
  • amount verification includes verifying whether the sum of the amount and the transaction amount of the last transaction sub-chain of each currency string certificate in at least one currency string certificate is equal.
  • the TEE sends a second verification instruction to the SE, where the second verification instruction may include the sub-chain digital signature of the penultimate transaction sub-chain, the last transaction sub-chain information, the sub-chain digital signature of the last transaction sub-chain. It can be understood that, the second verification instruction may also include other information capable of verifying the legitimacy of the data certificate, which is not particularly limited in this application.
  • the digital signature in each transaction sub-chain is obtained by digesting the data of the entire coin string certificate, in the process of generating the digital signature, the entire coin string needs to be The content of the certificate is completely transferred from the TEE to the SE. Due to the limitation of the transmission capability of the SE, the SE is not suitable for the transfer of large data. Therefore, this solution will affect the performance and experience of the terminal-side dual offline transaction scenario.
  • the sub-chain digital signature in each transaction sub-chain is a digital signature generated according to the digital signature result corresponding to the previous transaction and the current transaction data, the information required to generate the digital signature each time is a small amount , which can break the performance and storage bottlenecks of SE, and improve the performance of terminal-side transactions.
  • the SE verifying the legitimacy of the at least one data certificate according to the digital signature to be verified to obtain the second verification result includes verifying each coin in the at least one coin string certificate The legitimacy of the last transaction sub-chain of the string credentials.
  • the SE saves the sub-chain digital signature of the last transaction sub-chain, and the sub-chain of the last transaction sub-chain
  • the digital signature is used as a reference value for comparative verification in subsequent transactions.
  • the validity verification of the last transaction sub-chain may be implemented by verifying the sub-chain digital signature of the transaction sub-chain.
  • the SE after verifying the validity of the data certificate, the SE sends a second verification result to the TEE, where the second verification result indicates whether the at least one data certificate is legal or not. Verification passed.
  • the TEE receives the second verification result from the SE, the TEE saves the data certificate that passes the verification, and sends a second transaction response message to the REE, the second The transaction response message is used to indicate whether the transaction was successful. It can be understood that, when the validity verification of the at least one data credential fails, the TEE does not save the failed data credential after receiving the second verification result from the SE.
  • the REE after receiving the second transaction response message, the REE sends the second transaction response message to the first electronic device.
  • the second transaction response message is used to indicate to the transaction initiator of the first electronic device that the transaction is completed.
  • the second transaction response message may include an identifier indicating the success or failure of this transaction, and may also include a random number, which can be used as a A unique identifier that identifies this transaction. The random number is negotiated between the transaction initiator and the transaction receiver before passing the token string certificate.
  • the second transaction response message will be described by taking the confirmation message as an example.
  • the sub-chain digital signature of the last transaction sub-chain can verify the integrity and legality of the overall information of the currency string certificate. Therefore, as long as the sub-chain digital signature of the last transaction sub-chain is generated and verified in SE in the terminal-side interaction, it can achieve the same security effect as putting all verification calculations and data in SE.
  • the SE side retains the functions of generating signatures and verifying signatures, and other business logic is implemented on the TEE side to ensure equivalent security. Under the premise of breaking the performance and storage bottlenecks of SE, and improving the performance of end-to-end transactions.
  • the method further includes that the second electronic device synchronizes the data credential that has passed the legality verification to the server.
  • the timing of data voucher synchronization may be manually triggered by the user, or automatically triggered when the number of transactions reaches the upper limit, which is not limited in this application.
  • a third aspect a transaction verification method, wherein the method is applied to a server, comprising:
  • the server needs to perform overall verification on all the data vouchers, and the frequent and large number of verification data vouchers leads to high resource consumption and low performance.
  • incremental verification is performed on the data certificate on the server side, only the validity of the data in the data certificate that is more than the historical record is verified, and redundant verification calculations are reduced, thereby achieving high server concurrency scenarios.
  • the data certificate can be quickly verified and the effect of saving server resources.
  • the historical data credential is data related to the verified data credential. It should be noted that when the server saves the historical data certificate, it can only save the digital signature of the currency string certificate. It is also possible to save the entire coin string certificate.
  • the specific storage form is not limited in the embodiments of the present application. In the embodiment, description will be given by taking the server storing the digital signature of the coin string certificate as an example.
  • the data certificate includes a coin string certificate
  • the coin string certificate includes an original coin string or an original coin string and at least one transaction sub-chain
  • the original coin string includes the amount of the original coin string , issuer certificate and issuer signature
  • the transaction sub-chain includes transaction amount, transaction information, public key and sub-chain digital signature
  • the sub-chain digital signature is generated according to the digital signature corresponding to the previous transaction and the current transaction data digital signature.
  • Signature(n) Sign(Signature(n-1)+transaction(n))
  • Signature(n-1) identifies the digital signature generated by the previous transaction of this transaction
  • transaction(n) represents the current transaction related Information.
  • an incremental chain signature structure will be formed under this signature method.
  • the digital signature in each transaction sub-chain is obtained by digesting the data of the entire coin string certificate, that is, each time a digital signature is generated, an overall signature of all the preceding transaction data is required.
  • the chain signature scheme is used to replace the overall signature scheme, which reduces redundant digest calculations in the process of generating digital signatures for coin string certificates, improves the performance of terminal-side coin-string certificate generation, improves the user experience on the terminal side, and at the same time ensures the overall certificate. legality and integrity.
  • the coin string certificate includes a serial number, and the serial number is a unique identifier of the coin string certificate.
  • comparing the data voucher with the historical data voucher stored in the server includes: querying the server according to the serial number to see if there is a historical coin string voucher corresponding to the serial number, when When there is a historical coin string certificate with the same serial number as the coin string certificate, the server traverses the transaction sub-chain of the coin string certificate, and verifies that there are more outstanding coins in the coin string certificate than the historical coin string certificate. Validated transaction subchain.
  • the server has a historical coin string certificate with the same serial number as the coin string certificate, it traverses the digital signature data of the coin string certificate starting from the original coin string digital signature, and each The digital signature is compared with the nodes of the historical currency string certificate.
  • the currency string certificate verification fails; when the traversal is completed, all transaction sub-chain signatures of the currency string certificate are consistent, then the currency string certificate The certificate is valid; after all the branch nodes of the historical record are compared, if the coin string certificate still has the digital signature of the unverified transaction sub-chain, iteratively verify the digital signature of the remaining transaction sub-chain.
  • the method further includes the method further comprising: when the server does not have a historical coin string certificate with the same serial number as the coin string certificate, performing an update on the coin string certificate All transaction subchains are verified.
  • the verifying the transaction sub-chain includes verifying the digital signature, the signature of the issuer, the balance and the transaction flow. It is understandable that the balance and transaction flow can be synchronized to the server along with the token string certificate.
  • the storing the data certificate of successful verification includes storing the verified sub-chain digital signature of the transaction sub-chain as characteristic data in the server according to the serial number.
  • the server in the process of synchronizing the coin string certificate to the server, the server will verify the validity of the coin string certificate. After the verification is passed, the digital signature value of each transaction sub-chain will be used as the Transaction features, which save verified transaction data in a specific transaction tree structure.
  • the sub-chain digital signature of each transaction sub-chain of the coin string certificate is stored in the database of the server, wherein the coin string certificates of different serial numbers can be saved.
  • these saved data will be used as historical records, and will be used as reference values for comparative verification in the subsequent verification process, that is, in the process of verifying the signature of the transaction sub-chain, all coin string certificates will be stored in the transaction tree of the database.
  • the signatures that can be queried in the structure do not need to be repeatedly verified, just incremental verification of the nodes that do not exist in the database, and after the verification is successful, the verified nodes are added to the transaction tree structure for rapid verification of subsequent currency string certificates .
  • the coin string certificates of the same serial number will be continuously split and spread through transactions, and finally the coin string certificates held by multiple users have some duplicate information, and the verified transaction data will be stored during the synchronization process. It is stored in a specific transaction tree structure, so that the repeated information in the currency string certificates held by different users can be verified only by simple data comparison, without the need to repeatedly verify the signature, reducing the pressure of digital signature verification on the server side.
  • an embodiment of the present application further provides an apparatus for transaction verification, the apparatus having the function of implementing any one of the methods provided in the first aspect.
  • These functions can be implemented by hardware or by executing corresponding software by hardware.
  • the hardware or software includes one or more modules corresponding to the above functions.
  • the device may exist in the form of a chip product.
  • the transaction verification device may specifically be the first electronic device, or may be a fixed or removable functional module provided on the first electronic device.
  • an embodiment of the present application further provides an apparatus for transaction verification, the apparatus having the function of implementing any one of the methods provided in the second aspect.
  • These functions can be implemented by hardware or by executing corresponding software by hardware.
  • the hardware or software includes one or more modules corresponding to the above functions.
  • the device may exist in the form of a chip product.
  • the transaction verification device may specifically be the second electronic device, or may be a fixed or removable functional module provided on the second electronic device.
  • an embodiment of the present application further provides an apparatus for transaction verification, the apparatus having the function of implementing any one of the methods provided in the third aspect.
  • These functions can be implemented by hardware or by executing corresponding software by hardware.
  • the hardware or software includes one or more modules corresponding to the above functions.
  • the device may exist in the form of a chip product.
  • the transaction verification device may specifically be a server, or may be a fixed or removable functional module provided on the server.
  • an embodiment of the present application provides an electronic device, wherein the electronic device includes one or more processors, a memory, and one or more computer programs, wherein the one or more computer programs are stored In the memory, the one or more computer programs include instructions; when executed by the one or more processors, the instructions cause the electronic device to perform any one of the implementations of the first aspect. method; or, when the instructions are executed by the one or more processors, causing the electronic device to execute the method provided by any one of the implementation manners of the second aspect.
  • an embodiment of the present application provides a server, characterized in that the server includes one or more processors, a memory, and one or more computer programs, wherein the one or more computer programs are stored in a In the memory, the one or more computer programs include instructions; when the instructions are executed by the one or more processors, the instructions cause the server to execute the method provided by any one of the implementation manners of the third aspect.
  • an embodiment of the present application provides a transaction verification system, characterized in that the system includes a first electronic device, a second electronic device, and a server, and the first electronic device is configured to execute the process described in the first aspect.
  • the second electronic device is configured to execute the operation steps of the method described in the second aspect
  • the server is configured to execute the operation steps of the method described in the third aspect.
  • an embodiment of the present application provides a storage medium, which is characterized in that it includes a computer program, and when the computer program runs on one or more processors, is used to implement any implementation manner of the first aspect the method provided; alternatively, the computer program when running on one or more processors is used to implement the method provided by any one of the implementations of the second aspect; alternatively, the computer program when running on one or more processors When running on the processor, it is used to implement the method provided by any one of the implementation manners of the third aspect.
  • an embodiment of the present application provides a computer program or computer program product, characterized in that, when the computer program or computer program product runs on one or more processors, it is used to implement the first aspect.
  • an embodiment of the present application provides a chip system, including at least one processor and at least one interface circuit, where the at least one interface circuit is configured to perform a transceiving function, and send instructions to the at least one processor.
  • the processor executes the instructions, at least one processor executes the method provided by the first aspect to the third aspect and any of the possible implementation manners.
  • FIG. 1 is a schematic diagram of a system architecture for digital currency verification provided by an embodiment of the present application
  • FIG. 2 is a schematic structural diagram of a coin string voucher provided by the prior art
  • FIG. 3 is a schematic diagram of logical functions of a terminal device provided by the prior art
  • FIG. 5 is a schematic flowchart of a method for verifying digital currency by a cloud server provided by the prior art
  • FIG. 6 is a schematic structural diagram of a coin string certificate provided by an embodiment of the present application.
  • FIG. 7 is a schematic diagram of logical functions of a terminal device provided by an embodiment of the present application.
  • FIG. 8 is a schematic diagram of the logical structure of digital currency verification of a cloud-side issuer according to an embodiment of the present application.
  • FIG. 9 is a schematic structural diagram of a server storing a digital signature of a coin string certificate according to an embodiment of the present application.
  • 9a is a schematic diagram of a transaction branch provided by an embodiment of the present application.
  • FIG. 9b is a schematic diagram of another transaction branch provided by an embodiment of the present application.
  • FIG. 10 is a schematic flowchart of a server verifying digital currency provided by an embodiment of the present application.
  • FIG. 11 is a schematic flowchart of a terminal-side dual offline transaction provided by an embodiment of the present application.
  • FIG. 12 is a schematic device diagram of a first electronic device provided by an embodiment of the present application.
  • FIG. 13 is a schematic device diagram of a second electronic device provided by an embodiment of the present application.
  • FIG. 14 is a schematic diagram of an apparatus of a server according to an embodiment of the present application.
  • plural means two or more.
  • the term “and/or” or the character “/” in this application is only an association relationship to describe associated objects, indicating that there can be three kinds of relationships, for example, A and/or, or A/B, which can indicate: a separate relationship There are three cases where A exists, both A and B exist, and B exists alone.
  • the terminal-side system will be taken as an example to illustrate the functions of the above electronic devices, wherein the terminal device A is used as the first electronic device, and the terminal device B is used as the first electronic device.
  • the second electronic device is described as an example, and the digital signature of the transaction sub-chain will be replaced by the digital signature of the transaction sub-chain when describing the digital signature of the sub-chain of the transaction sub-chain.
  • FIG. 1 is a schematic diagram of a system architecture of digital currency verification provided by an embodiment of the present application.
  • the system in the embodiment of the present application is mainly divided into two parts: a cloud-side system and a terminal-side system, and currency string synchronization or online transactions can be performed between the cloud-side system and the terminal-side system, wherein:
  • the cloud-side system includes:
  • issuer A and issuer B are taken as examples for presentation, and the issuer may be a bank by way of example.
  • Central Bank Institution Interconnection Platform Connect all currency issuers through the central bank for transaction communications between institutions and the central bank's audit of various institutions.
  • issuer A and issuer B conduct institutional exchanges through the central bank's institution interconnection platform. interconnected.
  • the end-side system includes a terminal device security wallet application, and terminal device A and terminal device B are exemplarily shown in FIG. 1 .
  • the terminal device is a type of electronic device, and the electronic device includes but is not limited to: terminal device, fixed electronic device, and network device.
  • the terminal device may be a mobile terminal device or a fixed terminal device.
  • the electronic device may be an electronic device in the prior art, or may be an electronic device that will appear in the future.
  • the electronic device in the embodiments of the present application may be a mobile phone (mobile phone), a tablet computer (pad), a computer with a wireless transceiver function, a personal digital assistant (PDA), a smart watch, Netbooks, wearable electronic devices, augmented reality (AR) devices, virtual reality (VR) devices, in-vehicle devices, wireless terminals in industrial control, in self-driving wireless terminal in remote medical, wireless terminal in smart grid, wireless terminal in transportation safety, wireless terminal in smart city, smart home (smart home) wireless terminals, artificial intelligence (artificial intelligence, AI) terminals, etc.
  • mobile phone mobile phone
  • PDA personal digital assistant
  • PDA personal digital assistant
  • Netbooks wearable electronic devices
  • AR augmented reality
  • VR virtual reality
  • in-vehicle devices wireless terminals in industrial control, in self-driving wireless terminal in remote medical, wireless terminal in smart grid, wireless terminal in transportation safety, wireless terminal in smart city, smart home (smart home) wireless terminals, artificial intelligence (artificial intelligence
  • the embodiment of the present application provides a method for verifying digital currency, and the method can be applied to an electronic device.
  • the embodiments of the present application will be described by taking a terminal device as a kind of electronic device.
  • the technical solutions provided in the embodiments of the present application are applicable to terminal devices having a rich execution environment (Rich Execution Environment, REE), a trusted execution environment (Trusted Execution Environment, TEE) and a secure element (Secure Element, SE):
  • Rich execution environment REE module also known as the common execution environment, it is the execution environment for various applications of the operating system and its upper layers.
  • client wallet application implemented on the terminal device, also called the soft wallet, runs on the terminal Equipment REE environment;
  • TEE module It is implemented based on ARM's TrustZone technology, which defines a safe area on the main processor of mobile devices (including smartphones, tablets, set-top boxes, smart TVs, etc.), which can guarantee loading The security, confidentiality, and integrity of code and data into the environment.
  • the execution space provided by TEE has a higher level of security than the space provided by common mobile operating systems (such as Linux, Android, etc.).
  • TEE is usually used to run key operations: (1), mobile payment: fingerprint verification, PIN code input, etc.; (2), confidential data: secure storage of private keys, certificates, etc.; (3), content including: DRM (Digital copyright protection) etc.
  • TEE can provide security services for REE.
  • Security unit SE module It is a microprocessor chip used to store sensitive data and execute security applications. It can be used in scenarios such as identity authentication, digital signatures, and secure storage. It is an independent hardware-based operating environment that is not shared with the host machine. System resources, with the highest security level. However, due to the independent computing unit, the processing capacity is limited. Common applications are SIM cards issued by operators, encrypted SD cards from some security companies, or independent chip modules built into the device.
  • dual offline transaction means that both parties using the digital currency transaction are offline, and the transaction generated by only passing the currency string certificate through the terminal device, the transaction will be in the original currency.
  • a new transaction sub-chain is added to the end of the string voucher, the new transaction sub-chain will mark the current transaction amount, and the amount of the transaction sub-chain at the end represents the value of the new currency string voucher.
  • FIG. 2 it is a schematic structural diagram of a coin string certificate in the prior art.
  • the original currency string contains the necessary information such as the amount, currency issuer, and serial number when the currency is issued, and is signed by the currency issuer;
  • the full amount of data is signed at the end of each transaction.
  • the digital certificate structure of the currency consists of the original currency string and the transaction sub-chain to form a sequence structure.
  • the certificate transfer will generate a new transaction sub-chain, and a digital signature is added to ensure the integrity and validity of the data.
  • the end-side on the basis of the original coin string, after a transaction is performed, the end-side generates a digital signature 1 according to the data of the original coin string and the data of this transaction to describe the transaction sub-chain. 1, where transaction 1 and digital signature 1 constitute transaction sub-chain 1.
  • the digital signature 2 is generated according to the original currency string and the data related to the second transaction of the transaction sub-chain 1 to illustrate the legitimacy of the transaction sub-chain 2, wherein the transaction sub-chain 1 contains the digital signature 1.
  • Transaction 2 and digital signature 2 constitute transaction sub-chain 2. And so on.
  • FIG. 3 it is a schematic diagram of logical functions of a terminal device in the prior art.
  • the hard wallet logic of the terminal device is mainly implemented in the Applet application on the SE side, which defines the necessary interfaces and data for the hard wallet transaction process.
  • the main interface functions include: balance query, currency string synchronization, transfer in and out, currency string verification, etc.; the main data include user secret key, digital currency currency string certificate, transaction record, organization certificate, etc.
  • the user secret key is used for To identify the identities of both parties to the transaction.
  • TEE is only used to store simple user identification information such as fingerprint password, face, communication key, etc., among which, the communication key is used for channel encryption during communication between devices.
  • Steps S401-S402 the payer user initiates a payment request in the REE soft wallet, and the REE generates a payment instruction that interacts with the SE;
  • Step S403 After receiving the payment instruction, the payer SE executes the corresponding logical preparation transaction, such as balance verification;
  • Steps S404-S405 The payer SE splices the transaction sub-chain at the end of the coin string voucher to generate a new coin string voucher, and returns the coin string voucher to REE;
  • Step S406 After the payer REE generates a payment instruction according to the new currency string certificate, it sends it to the payee;
  • Step S407 the payee REE transparently transmits the payment instruction to SE;
  • Steps S408-S409 the payee SE verifies the coin string certificate, and saves the coin string certificate locally after the verification is passed;
  • Steps S410-S412 The payee returns the transaction confirmation information, and the payer completes the transaction after receiving it.
  • FIG. 5 it is a schematic flowchart of a method for verifying digital currency by a cloud server provided in the prior art. Specific steps are as follows:
  • Step S501 The terminal user connects to the server of the issuer, and uploads the coin string certificate with N transaction sub-chains, and the balance and transaction flow data related to the coin string;
  • Steps S502-S506 the cloud server parses the coin string certificate data, extracts the digital signature of the transaction sub-chain from the back to the front in the coin string certificate, and sequentially uses the corresponding signature algorithm such as the national secret algorithm for verification;
  • Steps S507-S508 After the signatures of all the transaction sub-chains are verified, extract the institutional signature of the original coin string and the original coin string data, and verify the legitimacy of the original coin string through the institutional signature of the original coin string and the original coin string data ; If the verification of the institutional signature of the original currency string is unsuccessful, the verification process fails, as shown in step S511, the process ends.
  • Steps S509-S510 After the institutional signature verification of the original coin string is passed, verify the validity of the balance and the running water. If the verification is successful, the coin string certificate is valid, and the verification process ends.
  • a transaction sub-chain will be added to the token string certificate every time it is passed, and all the certificate data needs to be digitally signed each time, which puts pressure on the end-side signature verification.
  • the hard wallet logic of the terminal device is mainly implemented in SE, and TEE is only used to store simple user identification information such as fingerprints and faces.
  • the terminal SE is an independent operating environment with hardware isolation, and the storage space and computing performance are limited.
  • the security of the device-side TEE is slightly lower than that of the SE, but the performance is much higher than that of the SE.
  • Most of the business logic is implemented in the SE.
  • the TEE only implements simple functions and does not fully utilize the performance.
  • the embodiments of the present application provide a method for verifying digital currency.
  • the method is based on the system architecture shown in FIG. 1 , and the method mainly includes the following technical points:
  • the digital signature of the token string certificate adopts a chain structure: as the transaction progresses, each transaction will generate a transaction sub-chain, in which the digital signature in each transaction sub-chain is based on the signature result of the previous transaction.
  • the digital signature of the last transaction sub-chain can verify the integrity and legitimacy of the overall information of the coin string certificate. Therefore, in the terminal-side interaction process, the business logic on the SE side is transferred to the TEE side for execution, and the digital signature verification process to ensure the legality of the transaction is retained in the SE.
  • the cloud server side After the cloud server side receives the coin string certificate synchronized by the terminal side, it builds a coin string certificate transaction tree, and saves the digital signature of the verified transaction sub-chain in a tree structure. During the verification process, the digital signature of the transaction sub-chain is stored. Incremental verification is performed. During the process of verifying the signature of the transaction sub-chain, the signatures that can be queried in the transaction tree structure of the database do not need to be repeatedly verified, and only the nodes that do not exist in the database need to be incrementally verified. After the verification is successful, the verified node is added to the transaction tree structure for quick verification of the subsequent token string certificate.
  • FIG. 6 it is a schematic structural diagram of the coin string certificate provided by the embodiment of the present application.
  • the end-side on the basis of the original coin string, after a transaction is performed, the end-side generates a digital signature 1 according to the data of the original coin string and the data of this transaction to describe the transaction sub-chain. 1, where transaction 1 and digital signature 1 constitute transaction sub-chain 1.
  • digital signature 2 is generated according to digital signature 1 and data related to the second transaction to illustrate the legitimacy of transaction sub-chain 2, wherein transaction 2 and digital signature 2 constitute transaction sub-chain 2 , and so on.
  • the digital signature in the transaction sub-chain and the institutional signature in the original currency string are presented separately.
  • the transaction sub-chain can contain digital signatures
  • the original currency string can contain institutional signatures.
  • Replacing the overall signature scheme with a chain signature scheme reduces redundant digest calculations in the process of generating digital signatures for coin string certificates and verifying digital signatures, improving the performance of terminal-side coin-string certificate generation and verification, and improving terminal-side user experience , while ensuring the legitimacy and integrity of the overall certificate.
  • FIG. 7 it is a schematic diagram of logical functions of a terminal device according to an embodiment of the present application.
  • the terminal device includes a rich execution environment (REE), a trusted execution environment (TEE), and a secure element (SE).
  • REE rich execution environment
  • TEE trusted execution environment
  • SE secure element
  • the trusted execution environment TEE implements most of the logic in the digital currency transaction process, including balance query, currency string synchronization, transfer in and out, etc., and also saves fingerprint passwords, communication keys, and organization certificates. , digital currency strings, transaction records, etc.
  • the computing performance and storage space of TEE are better than SE, so it can make full use of the performance of the device side and improve user experience.
  • the security unit SE defines two aspects of the necessary interface and data in the transaction process of the hard wallet: the interface is mainly to verify the digital signature of the transaction sub-chain at the end of the coin string certificate, which is used by the payee to verify the legitimacy of the incoming coin string certificate; data It is mainly the digital signature of the transaction sub-chain at the end of the currency string certificate, which is used to ensure that the currency string on the TEE side has not been tampered with before the payer's transaction.
  • the digital signature of the transaction sub-chain at the end of the transaction will also change. After entering the SE, it is found that it is inconsistent with the digital signature stored in the SE when the currency string certificate was received, and the verification fails. .
  • the payee When the payee receives the legal coin string certificate, it will verify the digital signature of the end transaction sub-chain in SE. After the digital signature verification is successful, the digital signature of the end transaction sub-chain corresponding to the coin string certificate will be stored in SE. Therefore, the security of the transaction is still guaranteed by SE, but the performance is greatly improved by using TEE.
  • FIG. 8 it is a schematic diagram of the logical structure of the digital currency verification of the cloud-side issuer provided by the embodiment of the present application.
  • each logic module In the distribution structure, the functions of each logic module are as follows:
  • Coin string certificate parsing analyze the content of each part of the coin string certificate from the data uploaded by the user, mainly extract the institutional signature and the digital signature of the transaction sub-chain;
  • Digital signature verification According to the chain signature method in the solution of the present invention, the legality of all digital signatures on the coin string certificate is verified, and the verified digital signatures are saved in the storage structure of the transaction tree;
  • each unique serial number When the digital currency is uploaded to the background of the issuer, each unique serial number will generate a tree structure composed of nodes representing digital signature information.
  • the traversal path from the root of the tree to a certain leaf node represents a currency
  • the tree structure formed represents the entire circulation and transmission process of the original coin string.
  • Serial number query in the storage in the backend of the issuer, query the corresponding verification data according to the serial number of the token string certificate, that is, the transaction tree associated with the serial number;
  • Digital signature comparison traverse the digital signature data in the token string certificate and compare it with the verified transaction tree nodes. If unverified nodes are found, incremental verification is performed on these nodes.
  • FIG. 9 a schematic structural diagram of a server storing a digital signature of a coin string certificate provided by an embodiment of the present application.
  • the digital signature x-n represents the digital signature generated by the payer x using the nth payment transaction of the currency string certificate, and the private key of the payer x is used.
  • the tree structure as shown in the figure is constructed and stored in the database.
  • Each node is the digital signature value of the corresponding transaction sub-chain. The relationship is determined by the chain signature method defined in the previous token string certificate.
  • FIG. 9a a schematic diagram of a transaction branch provided by an embodiment of the present application is shown.
  • a transaction branch is formed as shown in Figure 9a, in which the line b represents the transaction in which user A pays user B, and the line d represents the transaction in which user B pays user D.
  • the verification content includes: the institutional signature of the original coin string, and the digital signature A-1 is verified according to the content of the transaction subchain b and the institutional signature.
  • the content of sub-chain d and digital signature A-1 verify digital signature B-1; similarly, if the transaction sub-chain is longer, the signature can be iteratively verified.
  • FIG. 9b another schematic diagram of a transaction branch provided by an embodiment of the present application.
  • the transaction branch as shown in Figure 9b is formed, in which it can be confirmed that transaction branches b and d have been verified by the coin string certificate uploaded by user D and are legal through a simple comparison of signature values.
  • User F's digital signature is verified Just verify the transaction f that user D paid to user F with digital signature D-1.
  • FIG. 10 a schematic flowchart of a server verifying digital currency is provided in an embodiment of the present application, and the method may include steps S1001 to S1010, and the details are as follows:
  • Step S1001 The user uploads the currency string certificate to the issuer server during the synchronization process.
  • each coin string certificate needs to carry complete information including: original coin string amount, issuing agency certificate, issuing agency signature, transaction sub-chain generated by each transaction, and each transaction sub-chain also includes: transaction Amount and transaction information include transaction index, payer's public key, payer's signature, etc.
  • N the number of transaction sub-chains of a token string certificate
  • Step S1002 Query corresponding verification data according to the coin string serial number.
  • This step is performed before the specific verification of the digital signature of the coin string certificate.
  • the serial number information is extracted from the coin string certificate, and then it is queried in the database whether the serial number has a verified record.
  • steps S1009-S1010 that is, verify the digital signature one by one transaction sub-chain in a manner consistent with the existing scheme, the specific process is shown in Figure 5, and then construct the digital signature data of each transaction sub-chain as a node into a The branch structure starting from the institutional signature of the original coin string is used for the quick verification of the subsequent coin string certificate. At this point, the process ends;
  • Step S1003 Compare the digital signature of the local currency string certificate with the verified digital signature stored in the branch node. In this step, it is necessary to traverse the digital signature data of the currency string certificate starting from the institutional signature of the original currency string, and compare it with the node data of the verified branch. compare;
  • Step S1004 Determine whether there are inconsistent nodes: if there are nodes with inconsistent data, the verification of the coin string certificate fails, and the process ends; otherwise, steps S1005-S1008 are performed.
  • Steps S1005-S1008 Obtain the number M of verified transaction sub-chains:
  • M ⁇ N it means that the digital signature of the unverified transaction sub-chain still exists in the token string certificate, then iteratively verifies the digital signature of the remaining transaction sub-chain, and then saves the digital signature of the successfully verified transaction sub-chain on the additional branch node. , which is used for quick verification of subsequent coin string credentials. After all digital signature verification is valid, it proves that the currency string certificate is valid, and other verification processes can be carried out, such as flow verification, balance verification, etc.
  • FIG. 11 a schematic flowchart of a terminal-side dual offline transaction is provided in this embodiment of the present application.
  • This process includes a schematic diagram of the process between two terminal devices for offline transactions.
  • other scenarios are also included, such as online process, single offline process (including online payer and payee offline, or offline payee and online payee). It is understandable that when the actual application scenario is a single offline process , the local processing of the payer or payee process is the same as that of the payer or payee in the dual offline process, respectively.
  • Step S1101 The user operates the wallet App on the REE side to initiate a payment request.
  • the payer user negotiates the target address of the payee according to other channels, and sends a payment request to the TEE according to the corresponding TEE interface.
  • Step S1102 The payer TEE reads the currency string voucher stored in the TEE, and generates a payment instruction.
  • TEE will select the appropriate currency string according to the payment amount, and after basic verification in TEE, extract the digital signature at the end of the currency string certificate, and transfer the digital signature to SE.
  • the basic verification includes verifying whether the transaction amount is legal; or whether the initial set limit information such as wallet limit, transaction times, transaction limit, etc. is legal, these limit information can be saved in TEE or SE, if saved in SE, can be downloaded from The SE is read into the TEE and verified by the TEE. The number of transactions can be judged by the number of transaction sub-chains or the length of the token string certificate.
  • Step S1103 the payer SE executes the payment instruction logic
  • Step S1104 The payer SE compares the digital signature received from the TEE with the digital signature of the end transaction sub-chain saved after the last transaction verification passed. If the digital signature of the end transaction sub-chain of this transaction is the same as the one in SE If the digital signatures are consistent, it can be proved that the coin string data in TEE has not been tampered with, because the digital signature of the end transaction sub-chain stored in SE has not been changed in SE since the last transaction.
  • Steps S1105-S1106 The payer SE generates a new transaction sub-chain, and returns the new transaction sub-chain to the payer TEE.
  • the transaction sub-chain data is generated according to the transaction amount and random numbers or other reserved fields required by the payer for this transaction, and a new transaction sub-chain is generated according to the digital signature of the transaction sub-chain at the end of the previous transaction and the data of the current transaction sub-chain.
  • Transaction signature and finally splicing the transaction information and digital signature into a new transaction sub-chain and returning it to the TEE, wherein the SE generates transaction information according to the transaction amount.
  • Step S1107 The payer TEE splices the new transaction sub-chain returned by the SE to the original currency string voucher, generates a payment instruction and sends it to the payee.
  • Step S1108 The payee REE transparently transmits the payment request to the TEE, and the TEE executes the payment logic after receiving the payment request, and extracts all the data of the currency string certificate from the payment request.
  • Steps S1109-S1113 The payee cooperates to verify the coin string certificate at TEE and SE.
  • the instruction in the prior art is a payment instruction, which includes the entire coin string; originally, SE saved the entire coin string.
  • the payee performs most of the coin string verification logic in the TEE, including institutional signature verification of the original coin string, balance verification, and digital signature verification of the transaction sub-chain.
  • the information necessary for the verification of the final signature is passed to SE for verification through the verification instruction, wherein the necessary information for the verification of the final signature includes the digital signature of the penultimate transaction sub-chain , the information of the end transaction sub-chain, and the digital signature of the end transaction sub-chain.
  • the digital signature of the sub-chain of the transaction at the end is saved in SE for comparison and verification before payment of subsequent transactions, and the verification result is returned to TEE at the same time.
  • TEE confirms the verification result, stores the new token string certificate locally in TEE, and sends confirmation information to the payer after successful verification.
  • Steps S1114-S1115 The payer receives the confirmation information, verifies the confirmation information and completes the transaction.
  • the coin string is marked to delete the coin string identifier, and the server will delete the coin string certificate according to the identifier when the coin string certificate is subsequently synchronized to the server.
  • the confirmation information here is an example of the second transaction response message in the foregoing summary of the invention.
  • the digital currency verification apparatus includes corresponding hardware structures and/or software modules for performing each function.
  • the present application can be implemented in hardware or a combination of hardware and computer software with the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein. Whether a function is performed by hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Skilled artisans may implement the described functionality using different methods for each particular application, but such implementations should not be considered beyond the scope of this application.
  • the embodiments of the present application may divide the functional units of the digital currency verification device according to the above method examples.
  • each functional unit may be divided corresponding to each function, or two or more functions may be integrated into one processing unit.
  • the above-mentioned integrated units may be implemented in the form of hardware, or may be implemented in the form of software functional units. It should be noted that the division of units in the embodiments of the present application is illustrative, and is only a logical function division, and other division methods may be used in actual implementation.
  • the apparatus 1200 includes a rich execution environment REE module 1201, a trusted execution environment TEE module 1202, and a security element SE module 1203:
  • the rich execution environment REE module 1201 is configured to: send a first transaction request message to the execution environment TEE module, where the first transaction request message includes the transaction type of the transaction and the identifier of the transaction recipient;
  • the trusted execution environment TEE module 1202 is configured to: execute first business logic according to the transaction type to obtain a first verification instruction, and send the first verification instruction to the security unit SE module 1203, the first verification instruction
  • the instruction contains a digital signature
  • the security unit SE module 1203 is configured to: verify the validity of the transaction according to the digital signature to obtain a first verification result, and send the first verification result to the trusted execution environment TEE module;
  • the trusted execution environment TEE module 1202 is further configured to: send a first transaction response message to the rich execution environment REE module, where the first transaction response message includes the first verification result;
  • the rich execution environment REE module 1203 is further configured to: send a second transaction request message to the second electronic device according to the recipient identifier.
  • the trusted execution environment TEE module 1202 is further configured to save at least one data credential; and execute the first business logic according to the transaction type and the at least one data credential.
  • the data certificate includes a coin string certificate
  • the coin string certificate includes an original coin string or an original coin string and at least one transaction sub-chain
  • the transaction sub-chain includes a digital signature
  • the digital signature is used for Indicates the legitimacy of the transaction sub-chain
  • the original coin string includes the original coin string amount, the issuer's certificate, and the issuer's signature.
  • the first transaction request message further includes a transaction amount
  • the TEE module 1202 of the trusted execution environment is specifically configured to: extract the transaction amount from the at least one coin string certificate according to the transaction type and the transaction amount.
  • Select at least one coin string voucher ; perform basic verification on the selected at least one coin string voucher, the basic verification includes transaction times or transaction limit verification; after the basic verification is passed, extract each coin in the at least one coin string voucher
  • the digital signature of the last transaction sub-chain of the string voucher is generated, and the digital signature of the last transaction sub-chain of each coin string voucher and the first verification instruction of the transaction amount are generated.
  • the coin string certificate includes a serial number, and the serial number is the unique identifier of the coin string certificate; the security unit SE module 1203 is specifically used for: according to all the information in the first verification instruction. Generate transaction information from the transaction amount; compare the locally stored signature with the digital signature of the last transaction sub-chain in the first verification instruction according to the serial number, when the locally stored signature and the first verification instruction are compared. When the digital signatures of the last transaction sub-chain in the verification instruction are consistent, a second digital signature is generated according to the transaction information, the digital signature of the last transaction sub-chain and the locally stored private key; according to the second digital signature The signature and the transaction information generate a new transaction sub-chain; and a first verification result including the new transaction sub-chain is generated.
  • the TEE module 1202 of the trusted execution environment is specifically configured to update the new transaction sub-chain to the coin string certificate according to the serial number.
  • the rich execution environment REE module 1203 is further configured to synchronize the data credential to the server.
  • FIG. 13 it is a schematic diagram of an apparatus of a second electronic device according to an embodiment of the present application.
  • the apparatus 1300 includes a rich execution environment REE module 1301, a trusted execution environment TEE module 1302 and a security element SE module 1303:
  • the rich execution environment REE module 1301 is configured to: receive a second transaction request message from the first electronic device, and send the second transaction request message to the trusted execution environment TEE module 1302, the second transaction request message
  • the request message includes at least one data certificate, wherein the data certificate includes a serial number, and the serial number is a unique identifier of the data certificate;
  • the trusted execution environment TEE module 1302 is configured to: execute the second business logic according to the at least one data credential to obtain a second verification instruction, and send the second verification instruction to the security unit SE module 1303, and the first verification instruction is sent to the security unit SE module 1303. 2. Verify that the instruction includes a digital signature;
  • the security unit SE module 1303 is configured to: verify the validity of the at least one data credential according to the digital signature to obtain a second verification result, and send the second verification result to the trusted execution environment TEE module 1302, the second verification result indicates whether the validity of the at least one data credential is verified;
  • the Trusted Execution Environment TEE module 1302 is further configured to: receive the second verification result from the security unit SE module 1303, save the verified data certificate, and send a second transaction response message to the Rich Execution Environment REE module 1301, the second transaction response message is used to indicate whether the transaction is successful;
  • the rich execution environment REE module 1301 is further configured to: send a second transaction response message to the first electronic device.
  • the data certificate includes a coin string certificate
  • the coin string certificate includes an original coin string or an original coin string and at least one transaction sub-chain
  • the transaction sub-chain includes a digital signature
  • the digital signature is used for Indicates the legitimacy of the transaction sub-chain
  • the original coin string includes the original coin string amount, the issuer's certificate, and the issuer's signature.
  • the second business logic includes the verification of the institutional signature of the original coin string or the verification of the previous transaction of the last transaction sub-chain of the coin string certificate.
  • the security unit SE module 1303 is specifically configured to verify the legitimacy of the last transaction sub-chain of each data certificate of the at least one data certificate.
  • the security unit SE module 1303 is also used to save the digital signature of the last transaction sub-chain after the validity verification of the last transaction sub-chain passes, and the digital signature is used for subsequent transactions. as a reference value for comparison and verification.
  • FIG. 14 it is a schematic diagram of an apparatus of a server according to an embodiment of the present application.
  • the apparatus 1400 includes:
  • a receiving module 1401, configured to receive a data certificate from an electronic device
  • the verification module 1402 is configured to perform incremental verification on the data certificate, the incremental verification includes comparing the data certificate with the historical records saved in the server, and verifying that the data certificate is higher than the historical records. The legitimacy of redundant data, wherein the historical record is a verified historical data certificate;
  • the saving module 1403 is configured to save the data certificate that is successfully authenticated.
  • the data certificate includes a coin string certificate
  • the coin string certificate includes an original coin string or an original coin string and at least one transaction sub-chain
  • the original coin string includes the amount of the original coin string
  • the issuer The certificate and the signature of the issuer
  • the transaction sub-chain includes transaction amount, transaction information, public key and digital signature
  • the digital signature is a digital signature generated according to the signature result of the previous transaction and the current transaction data.
  • the coin string certificate includes a serial number, and the serial number is the unique identifier of the coin string certificate; the verification module 1402 is specifically configured to query whether the server has a connection with the serial number according to the serial number.
  • the historical coin string certificate corresponding to the name number when the server has a historical coin string certificate with the same serial number as the coin string certificate, traverse the transaction sub-chain of the coin string certificate, and verify that the coin string certificate is higher than the The unverified transaction sub-chain that is added to the historical currency string certificate.
  • the verification module 1402 is specifically configured to perform verification on all transaction sub-chains in the coin string certificate when the server does not have a historical coin string certificate with the same serial number as the coin string certificate. verify.
  • the verification module 1402 is specifically used to verify the digital signature, the signature of the issuer, the balance and the transaction flow.
  • the saving module 1403 is specifically configured to store the verified digital signature of the transaction sub-chain as characteristic data in the server according to the serial number.
  • the processing unit may be a processor or a controller.
  • the storage unit may be a memory.
  • the actions performed by the above functional units may be performed by the processor according to programs stored in the memory.
  • Embodiments of the present application also provide a computer-readable storage medium, including instructions, which, when executed on a computer, cause the computer to execute the above method.
  • Embodiments of the present application also provide a computer program or computer program product containing instructions, which, when run on a computer, cause the computer to execute the above method.
  • the computer program product includes one or more computer instructions.
  • the computer may be a general purpose computer, a special purpose computer, a computer network, or other programmable device.
  • Computer instructions may be stored in or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions may be transmitted from a website site, computer, server, or data center over a wire (e.g.
  • Coaxial cable, optical fiber, digital subscriber line (DSL) or wireless means to transmit to another website site, computer, server or data center.
  • Computer-readable storage media can be any available media that can be accessed by a computer or data storage devices including one or more servers, data centers, etc., that can be integrated with the media.
  • Useful media may be magnetic media (eg, floppy disk, hard disk, magnetic tape), optical media (eg, DVD), or semiconductor media (eg, solid state disk (SSD)), and the like.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Finance (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Technology Law (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

一种交易验证的方法及装置，用于计算机技术领域。其中，该方法应用于包括安全单元SE、可信执行环境TEE和富执行环境REE的电子设备，包括在交易验证过程中，将业务逻辑的执行和数据存储从SE侧转移到TEE侧实现，SE侧保留交易合法性验证，在保证安全性的前提下，克服了电子设备SE存储空间与计算性能受限的问题，显著提升了用户体验。所述方法也应用于服务器侧，包括对来自电子设备的数据凭证进行增量验证，验证所述历史数据凭证没有记录的所述数据凭证中的数据的合法性。减少了服务器侧的冗余的验证计算，从而达到高并发场景下在服务器侧快速验证数据凭证、节省资源的效果。

Description

交易验证的方法、装置 技术领域
本申请实施例涉及计算机技术领域，尤其是涉及交易验证的方法。
背景技术
随着电子商务与移动支付的快速发展，传统的金融体系和技术正不断受到挑战。基于区块链技术的比特币也将数字货币这一概念带入大众视野，世界各主要经济体都在着手研究和推广数字货币相关技术。
数字货币一般由国家央行发行，为了实现高性能、高可用、高性能的数字货币，业界普遍采用区块链与分布式账本技术或者基于既有银行系统的中心化金融账户体系来实现。然而区块链与分布式账本技术虽然有很多优点，比如数据天然不可篡改和分布式一致性，但仍存在很多不足：区块链技术依旧处于发展阶段，当前的性能可能不足以支撑数字货币大规模应用后带来的交易压力。因此，基于既有的中心化银行系统架构方案反而是优先选择的实现方案，但这种方案在交易验证中依旧存在性能瓶颈。
为了解决这个问题，业界已经存在一种实现可控匿名的数字货币的技术，即在既有中心化银行系统中模拟了类似现金交易的模型来实现数字货币的离线、在线交易。数字货币的币串凭证由原始币串与若干交易子链组成。在该现有技术中，以原始币串为基础，随着数字货币的流通，会不断在币串凭证末尾追加新的交易子链，并在每次交易后针对币串凭证的整体数据生成数字签名、验证数字签名的有效性。现有技术能够有效实现数字货币在线、离线交易的功能，解决币串凭证的合法性和安全性问题，然而仍然存在验证过程中存在一定的冗余计算以及受限于性能用户体验较差的不足。
因此，如何提升数字货币的验证性能，提升用户体验成为亟待解决的问题。
发明内容
本申请实施例提供一种交易验证的方法和装置，应用于计算机技术领域，解决如下问题：
如何提升数字货币在交易过程中的验证性能，以提升用户体验。
为方便理解本申请的实施例，下面先对本申请中出现的部分技术概念做介绍。应理解的是，这些技术概念应用在本申请下文将要介绍的实施例中，但这些实施例仅是本发明提供的方案的部分实施例中，所以这些技术概念并非一定要应用在本申请所有实施例中。
软钱包：在电子设备上实现的客户端钱包应用程序，执行在富执行环境REE。
硬钱包：在电子设备上结合安全硬件特性在TEE和SE上实现的钱包业务逻辑和安全模块。
Applet：使用Java Card框架在SE中开发使用的应用程序。
发行机构：数字货币发行机构的后台服务，负责数字货币的验证、同步、审计等。
原始币串：用来表示数字货币价值的一种不可变的数据结构，有冠字号作为唯一标识，携带有货币发行机构和金额等信息。
机构签名：用来证明原始币串的合法性，由数字货币发行机构的私钥对原始币串进行数字签名生成。
交易子链：在两个用户进行交易时追加在原来的币串凭证上，用来记录一次付款行为的价值传递，包含交易金额等信息。
币串凭证：由原始币串和若干交易子链相连组成的，并由迭代的数字签名保证合法性。
前序交易：同一币串凭证上某一交易子链追加之前的币串凭证数据。
数字签名：在币串凭证的末尾追加的交易签名，用来证明交易子链及前序交易的合法性，由付款方私钥生成。
双离线交易：使用数字货币交易的双方均为离线状态下，仅通过终端设备传递币串凭证产生的交易，该交易会在原币串凭证结尾追加新的交易子链标记本次交易金额，末尾交易子链的金额表示了新币串凭证的价值。
冠字号：作为原始币串的唯一标识，与纸币的冠字号概念一致。
币串同步：随着用户使用数字货币的过程，用户硬钱包中会逐渐累积大量小额币串，此时硬钱包的性能会受到影响，因此需要用户与发行机构进行同步操作，将钱包中的小额币串整合为整额币串重新下发到钱包，或者存入自己的银行账户。
下面将从多个方面介绍本申请，容易理解的是，该以下多个方面可以单独实施，也可以选择其中任意两个或更多联合实施。该以下多个方面的实现和有益效果可互相参考。
在本申请的描述中，末尾交易子链和最后一个交易子链具有相同的含义。
第一方面，本申请实施例提供一种交易验证的方法，所述方法应用于包括安全单元SE、可信执行环境TEE和富执行环境REE的第一电子设备，所述方法包括：所述REE向所述TEE发送第一交易请求消息，所述第一交易请求消息包括交易的交易类型；所述TEE根据所述交易类型执行第一业务逻辑以获得第一验证指令，所述第一验证指令包括待验证的数字签名；所述TEE向所述SE发送所述第一验证指令；所述SE根据所述待验证的数字签名验证所述交易的合法性以获得第一验证结果，并将所述第一验证结果发送给所述TEE；所述TEE发送第一交易响应消息给所述REE，所述第一交易响应消息包含所述第一验证结果；所述REE在所述第一验证结果指示验证成功时，根据所述交易的接收方标识向第二电子设备发送第二交易请求消息，所述接收方标识用于指示所述第二电子设备。
示例性的，以用户在REE软钱包发起付款请求为例。用户在协商到收款方地址后，在REE侧软钱包发起付款操作，向TEE发起付款请求消息，在这个例子中，上述第一交易请求消息为付款请求。TEE收到付款请求消息后，执行第一业务逻辑即付款业务逻辑，如交易次数、交易限额等基本验证，并向SE发送第一验证指令，SE根据数字签名验证付款交易的合法性后将验证结果返回给TEE保存。而现有技术中，用户在协商到收款方地址后，在REE侧软钱包发起付款操作，并生成与SE交互的支付指令，由SE执行付款业务逻辑和保存币串凭证。
由于电子设备中SE为硬件隔离的独立运行环境，存储空间与计算性能受限，本申请相比现有技术，将第一业务逻辑和数据存储转移到TEE侧实现，SE侧保留交易合法性验证，在保证安全性的前提下，充分利用端侧性能，显著提升用户体验。
在一种可能的实现方式中，该方法还包括所述TEE保存了至少一个候选的数据凭证。
在一种可能的实现方式中，所述TEE根据所述交易类型执行第一业务逻辑包括所述TEE根据所述交易类型以及所述至少一个候选的数据凭证执行所述第一业务逻辑。
在一种可能的实现方式中，该方法还包括所述数据凭证为币串凭证，所述币串凭证包括原始币串或者原始币串以及至少一个交易子链，所述数字签名为在所述币串凭证末尾追加的交易签名，用于指示所述交易子链的合法性，所述原始币串包括原始币串金额、发行机构证书、发行机构签名，所述交易子链包括与所述交易子链对应的子链数字签名。
具体的，随着交易的进行，每次交易会产生交易子链，其中，每一个交易子链中的子链数字签名为根据前一次交易对应的数字签名结果与本次交易数据生成的数字签名，即Signature(n)＝Sign(Signature(n-1)+transaction(n))，其中，Signature(n-1)标识本次交易的前一次交易生成的数字签名，transaction(n)表示本次交易相关的信息。可以理解的是，这种签名方式下将形成一条增量的链式签名结构。而现有技术中，每一个交易子链中的数字签名是通过对整个币串凭证的数据做摘要计算得到的，即每次生成数字签名都需要对所有前序交易数据进行整体签名。用链式签名方案替代整体签名方案，在对币串凭证生成数字签名和验证数字签名的过程中减少了冗余的摘要计算，提高端侧币串凭证生成和验证的性能，提升端侧用户体验，同时保证了整体凭证的合法性和完整性。
在一种可能的实现方式中，所述第一交易请求消息还包括交易的交易金额。
在一种可能的实现方式中，所述TEE根据所述交易类型以及所述至少一个候选的数据凭证执行第一业务逻辑所述TEE根据所述交易类型以及所述交易金额从所述至少一个候选的币串凭证中选择待验证的币串凭证；所述TEE对所述待验证的币串凭证进行基本验证，所述基本验证包括交易次数或交易限额验证；所述TEE提取通过所述基本验证的币串凭证的最后一个交易子链的子链数字签名，生成所述第一验证指令，所述通过所述基本验证的币串凭证的最后一个交易子链的子链数字签名为所述待验证的数字签名，所述第一验证指令包括通过所述基本验证的币串凭证的最后一个交易子链的子链数字签名和所述交易金额。
具体的，所述TEE根据所述交易类型以及所述交易金额从所述至少一个候选的币串凭证中选择待验证的币串凭证，具体的，所述TEE可以在TEE保存的所有币串凭证中，从大额度的币串凭证开始选择至少一个币串凭证；也可以根据交易金额在TEE保存的币串凭证中选择一个余额和交易金额最接近的币串凭证；也可以在TEE保存的币串凭证中筛选出余额大于等于交易金额的币串凭证，然后根据一定的算法选择至少一个币串凭证；还可以限定选择某一发行机构、优先选择满足交易金额要求的单个最小余额的币串凭证或者优先选择整合多个小余额币串以满足交易金额要求；还可以根据其他规则对币串凭证进行选择，本申请实施例不做特别限制。
具体的，所述TEE对所述待验证的币串凭证进行基本验证可以包括验证交易金额、钱包限额、交易次数、交易限额等是否合法。验证交易金额可以包括验证币串凭证的余额是否满足交易金额的要求。币串凭证的余额可以保存到TEE中。钱包限额、交易次数、交易限额等可以通过预设到TEE上，由TEE进行验证；或者钱包限额、交易次数、交易限额等也可以预设到SE上，然后从SE读取到TEE，再在TEE上进行验证。以交易次数为例，可以通过判断交易子链个数或者币串凭证长度判断交易次数是否在预设的限额内。可以理解的是，前述基本验证仅是示例，本申请不对基本验证进行限制。
在一种可能的实现方式中，所述TEE提取通过所述基本验证的币串凭证的最后一个交易子链的子链数字签名，生成所述第一验证指令，所述通过所述基本验证的币串凭证的最后一个交易子链的子链数字签名为所述待验证的数字签名，所述第一验证指令包括通过所述基本验证的币串凭证的最后一个交易子链的子链数字签名和所述交易金额，所述TEE将第一验证指令发送给SE。
可以理解的是，在一些流程中，TEE不需要发送第一验证指令给SE。示例性的，当TEE在不需要由SE生成新的交易子链时，比如读取当前钱包的总余额等操作；或者首次收到新的币串凭证需要验证的情况下，不需要发送第一验证指令给SE。
在一种可能的实现方式中，所述通过所述基本验证的币串凭证包括冠字号，所述冠字号为所述通过所述基本验证的币串凭证的唯一标识；所述SE根据所述待验证的数字签名验证所述交易的合法性以获得第一验证结果包括：所述SE根据所述第一验证指令中的所述交易金额生成交易信息；所述SE根据所述冠字号将本地存储的参考数字签名与所述第一验证指令中的所述最后一个交易子链的子链数字签名进行对比，当所述本地存储的参考数字签名与所述第一验证指令中的最后一个交易子链的子链数字签名一致时，所述SE根据所述交易信息、所述最后一个交易子链的子链数字签名和所述SE本地保存的私钥生成与所述交易对应的数字签名；所述SE根据所述与所述交易对应的数字签名和所述交易信息生成与所述交易对应的交易子链，所述与所述交易对应的交易子链中的子链数字签名为所述与所述交易对应的数字签名；所述SE生成包括所述与所述交易对应的交易子链的第一验证结果。可以理解的是，所述SE可以将与交易对应的数字签名保存在本地。
可以理解的是，如果TEE选择的待验证币串凭证包含至少一个币串凭证，则第一验证指令中将包含所述至少一个币串凭证中每个币串凭证的最后一个交易子链的数字签名；SE收到第一验证指令后，将根据冠字号分别对第一验证指令中的每个最后一个交易子链的子链数字签名与SE本地存储的参考数字签名一一进行对比；当SE本地存储的参考数字签名与最后一个交易子链的子链数字签名一致时，所述SE根据所述交易信息、所述最后一个交易子链的子链数字签名和所述SE本地保存的私钥生成与所述交易对应的数字签名。可以理解的是，每次签名对比一致，将生成一个与交易对应的数字签名，SE将根据所述与所述交易对应的数字签名和所述交易信息生成与所述交易对应的交易子链。
示例性的，比如，交易发起方发起5块钱转账交易，若TEE在本地选择了5个1块钱的币串凭证，则TEE将把这5个1块钱的币串凭证的最后一个交易子链的子链数字签名发送给SE，SE收到后，将来自TEE的这5个1块钱的币串凭证的最后一个交易子链的子链数字签名根据冠字号分别与保存在本地的签名信息进行对比，每次对比一致时，生成一个与交易对应的数字签名和一个与交易对应的交易子链。若5个币串凭证的最后一个交易子链的子链数字签名都对比一致，则SE将生成5个与交易对应的数字签名和5个与交易对应的交易子链。第一验证结果中将包括这5个与交易对应的交易子链。
在一种可能的实现方式中，所述SE根据所述交易金额、收款方身份唯一标识、交易唯一标识、生成新交易子链中的交易信息部分。
在一种可能的实现方式中，所述TEE保存所述第一验证结果；所述TEE根据冠字号将所述与交易对应的交易子链更新到所述通过所述基本验证的币串凭证上。
在一种可能的实现方式中，所述方法还包括所述第一电子设备将所述更新后的所述通过所述基本验证的币串凭证同步到服务器。具体的，所述币串凭证同步的时机可以是用户手动触发同步，或者是交易次数达到上限时自动触发同步等，本申请不做限制。需要说明的是，所述第一电子设备在同步币串凭证到服务器时，也可以同步上传跟币串凭证相关的其他信息，如币串余额、交易流水等。
在一种可能的实现方式中，所述方法还包括所述第一电子设备接收第二电子设备的确认消息以完成交易。第一电子设备接收到确认消息后，判断在币串凭证的金额使用完的情况下，对所述币串凭证标记删除标识。在币串凭证同步到服务器后，若币串凭证标记有删除标识则由服务器对所述币串凭证进行删除。
第二方面，一种交易验证的方法，其特征在于，所述方法应用于包括安全单元SE、可信 执行环境TEE和富执行环境REE的第二电子设备，所述方法包括：所述REE接收来自第一电子设备的第二交易请求消息，并将所述第二交易请求消息发送给所述TEE，所述第二交易请求消息包含至少一个数据凭证；所述TEE根据所述至少一个数据凭证执行第二业务逻辑以获得第二验证指令，所述第二验证指令包括待验证的数字签名；所述TEE向所述SE发送所述第二验证指令；所述SE根据所述待验证的数字签名验证所述至少一个数据凭证的合法性以获得第二验证结果，并将所述第二验证结果发送给所述TEE，所述第二验证结果指示所述至少一个数据凭证的合法性是否验证通过；所述TEE接收来自所述SE的所述第二验证结果，保存所述验证通过的数据凭证，发送第二交易响应消息给所述REE，所述第二交易响应消息用于指示交易是否成功；所述REE发送第二交易响应消息给第一电子设备。
由于电子设备中，SE为硬件隔离的独立运行环境，存储空间与计算性能受限，通过本申请的方法，将第二业务逻辑和数据存储转移到TEE侧实现，SE侧保留数据凭证合法性验证，在保证安全性的前提下，充分利用端侧性能，显著提升用户体验。
在一种可能的实现方式中，所述数据凭证包括币串凭证，所述币串凭证包括原始币串或者原始币串以及至少一个交易子链所述原始币串包括原始币串金额、发行机构证书、发行机构签名，所述交易子链包括与所述交易子链对应的子链数字签名。
具体的，随着交易的进行，每次交易会产生交易子链，其中，每一个交易子链中的子链数字签名为根据前一次交易对应的数字签名结果与本次交易数据生成的数字签名，即Signature(n)＝Sign(Signature(n-1)+transaction(n))，其中，Signature(n-1)标识本次交易的前一次交易生成的数字签名，transaction(n)表示本次交易相关的信息。可以理解的是，这种签名方式下将形成一条增量的链式签名结构。而现有技术中，每一个交易子链中的数字签名是通过对整个币串凭证的数据做摘要计算得到的，即每次生成数字签名都需要对所有前序交易数据进行整体签名。用链式签名方案替代整体签名方案，在对币串凭证生成数字签名和验证数字签名的过程中减少了冗余的摘要计算，提高端侧币串凭证生成和验证的性能，提升端侧用户体验，同时保证了整体凭证的合法性和完整性。
在一种可能的实现方式中，所述币串凭证包括冠字号，所述冠字号为所述币串凭证的唯一标识。
在一种可能的实现方式中，所述第二业务逻辑包括原始币串的机构签名验证或所述币串凭证的最后一个交易子链的前序交易的验证。具体的，可以在TEE中执行大部分的币串验证逻辑，包括原始币串的机构签名验证以及除最后一个交易子链以外的其他交易子链的子链数字签名验证。TEE还可以进行金额验证，该金额验证包括验证至少一个币串凭证中的每个币串凭证的最后一个交易子链的金额总和交易金额是否相等。当验证到最后一个交易子链的数字签名时，TEE获取验证最后一个交易子链的子链数字签名所必要的信息，这些信息可以包括倒数第二个交易子链的子链数字签名、最后一个交易子链的信息、最后一个交易子链的子链数字签名。
在一种可能的实现方式中，所述TEE向所述SE发送第二验证指令，其中，所述第二验证指令可以包括倒数第二个交易子链的子链数字签名、最后一个交易子链的信息、最后一个交易子链的子链数字签名。可以理解的是，所述第二验证指令还可以包括其他能够验证所述数据凭证合法性的信息，本申请不做特别限制。
需要说明的是，在现有技术中，由于每一个交易子链中的数字签名是通过对整个币串凭证的数据做摘要计算得到的，因此在生成数字签名的过程中，需要将整个币串凭证的 内容完整地从TEE传入SE，由于SE的传输能力限制，SE并不适合传入传出较大的数据，因此这种方案会对端侧双离线交易场景的性能和体验产生影响。而在本申请中，由于每一个交易子链中的子链数字签名为根据前一次交易对应的数字签名结果与本次交易数据生成的数字签名，每次生成数字签名所需要的信息是少量的，从而能够打破SE的性能和存储瓶颈，提升端侧交易性能。
在一种可能的实现方式中，所述SE根据所述待验证的数字签名验证所述至少一个数据凭证的合法性以获得第二验证结果包括验证所述至少一个币串凭证中的每个币串凭证的最后一个交易子链的合法性。
在一种可能的实现方式中，所述最后一个交易子链的合法性验证通过后，所述SE保存所述最后一个交易子链的子链数字签名，所述最后一个交易子链的子链数字签名用于后续交易时作为对比验证的参考值。示例性的，所述最后一个交易子链的合法性验证可以通过验证该交易子链的子链数字签名来实现。
在一种可能的实现方式中，所述SE验证所述数据凭证的合法性后，将第二验证结果发送给所述TEE，所述第二验证结果指示所述至少一个数据凭证的合法性是否验证通过。
在一种可能的实现方式中，所述TEE接收来自所述SE的第二验证结果，所述TEE保存所述验证通过的数据凭证，发送第二交易响应消息给所述REE，所述第二交易响应消息用于指示交易是否成功。可以理解的是，当所述至少一个数据凭证的合法性验证失败时，所述TEE接收来自所述SE的所述第二验证结果后，不保存所述验证失败的数据凭证。
在一种可能的实现方式中，所述REE收到第二交易响应消息后，将第二交易响应消息发送给第一电子设备。第二交易响应消息用于向第一电子设备的交易发起方指示本次交易完成，第二交易响应消息可以包括指示本次交易成功或失败的标识，还可以包括随机数，该随机数可以作为标识本次交易的唯一标识，该随机数是在传递币串凭证前交易发起方和交易接收方协商的。在实施例中，将以确认消息为示例来说明第二交易响应消息。
由于币串凭证的链式签名结构，最后一个交易子链的子链数字签名可以验证币串凭证整体信息的完整性和合法性。因此只要在端侧交互操作中，将最后一个交易子链的子链数字签名在SE中生成和验证，即可以达到和所有验证计算和数据都放在SE中一样的安全性效果。
本申请中仅将最后一个交易子链的子链数字签名和用户密钥存储在SE中，SE侧保留生成签名和验证签名的功能，其他的业务逻辑在TEE侧实现，在保证等效安全性的前提下，打破SE的性能和存储瓶颈，提升端侧交易性能。
在一种可能的实现方式中，所述方法还包括第二电子设备将合法性验证通过的数据凭证同步到服务器。数据凭证同步的时机可以是用户手动触发同步，或者是交易次数达到上限时自动触发同步等，本申请不做限制。
第三方面，一种交易验证的方法，其特征在于，所述方法应用于服务器，包括：
接收来自电子设备的数据凭证；对所述数据凭证进行增量验证，所述增量验证包括将所述数据凭证与保存在所述服务器的历史数据凭证进行对比，验证所述历史数据凭证没有记录的所述数据凭证中的数据的合法性；保存所述合法性验证成功的所述数据凭证。
现有技术中，服务器在验证过程中，需要对所有的数据凭证数据进行整体验证，频繁、大量验证数据凭证导致资源消耗大、性能低。通过本申请，在服务器侧通过对数据凭证进行增量验证，仅验证所述数据凭证中比所述历史记录多余的数据的合法性，减少了冗余的验证计算，从而达到服务器高并发场景下的数据凭证能够快速验证、节省服务器资源的效果。
在一种可能的实现方式中，所述历史数据凭证为已验证的数据凭证相关的数据。需要说明的是，服务器在保存历史数据凭证时，可以只保存该币串凭证的数字签名。也可以保存整个币串凭证。具体的保存形式，本申请实施例不做限制。在实施例中，将以服务器存储币串凭证的数字签名为示例进行说明。
在一种可能的实现方式中，所述数据凭证包括币串凭证，所述币串凭证包括原始币串或者原始币串以及至少一个交易子链，其中，所述原始币串包括原始币串金额、发行机构证书和发行机构签名，所述交易子链包括交易金额、交易信息、公钥和子链数字签名，所述子链数字签名为根据前一次交易对应的数字签名与本次交易数据生成的数字签名。
具体的，随着交易的进行，每次交易会产生交易子链，其中，每一个交易子链中的数字签名为根据前一次交易对应的数字签名结果与本次交易数据生成的数字签名，即Signature(n)＝Sign(Signature(n-1)+transaction(n))，其中，Signature(n-1)标识本次交易的前一次交易生成的数字签名，transaction(n)表示本次交易相关的信息。可以理解的是，这种签名方式下将形成一条增量的链式签名结构。而现有技术中，每一个交易子链中的数字签名是通过对整个币串凭证的数据做摘要计算得到的，即每次生成数字签名都需要对所有前序交易数据进行整体签名。用链式签名方案替代整体签名方案，在对币串凭证生成数字签名的过程中减少了冗余的摘要计算，提高端侧币串凭证生成的性能，提升端侧用户体验，同时保证了整体凭证的合法性和完整性。
可以理解的是，基于上述数字签名的生成过程，当币串凭证同步到服务器、服务器进行数字签名验证时，能够减少冗余的摘要计算、提高验证的性能，提升端侧用户体验，同时保证了整体凭证的合法性和完整性。
在一种可能的实现方式中，所述币串凭证包括冠字号，所述冠字号为所述币串凭证的唯一标识。
在一种可能的实现方式中，将所述数据凭证与保存在所述服务器的历史数据凭证进行对比包括：根据冠字号查询所述服务器是否存在与所述冠字号对应的历史币串凭证，当所述服务器存在与所述币串凭证具有相同冠字号的历史币串凭证时，遍历所述币串凭证的交易子链，验证所述币串凭证中比所述历史币串凭证多出的未验证的交易子链。示例性的，当所述服务器存在与所述币串凭证具有相同冠字号的历史币串凭证时，从原始币串数字签名开始遍历币串凭证的数字签名数据，将该币串凭证中每个数字签名与该历史币串凭证的节点进行对比，一旦存在数据不一致的节点，则该币串凭证验证失败；当遍历结束后，币串凭证的所有交易子链签名均对比一致，则该币串凭证有效；当该历史记录的所有分支节点均对比完成后，若币串凭证还存在未验证的交易子链的数字签名时，则迭代验证剩余的交易子链数字签名。
在一种可能的实现方式中，所述方法还包括所述方法还包括当所述服务器不存在与所述币串凭证具有相同冠字号的历史币串凭证时，对所述币串凭证中的所有交易子链进行验证。
在一种可能的实现方式中，所述对交易子链进行验证包括验证数字签名、发行机构签名、余额和交易流水。可以理解的是，余额和交易流水可以随币串凭证一起同步到服务器的。
在一种可能的实现方式中，所述保存验证成功的所述数据凭证包括根据冠字号将已验证的所述交易子链的子链数字签名作为特征数据存储到所述服务器。
具体的，基于上述的链式结构的数字签名方案，在币串凭证同步到服务器的过程中，服务器将验证币串凭证的有效性，验证通过后，以每个交易子链的数字签名值作为交易特征，将已验证的交易数据保存在特定的交易树结构中。示例性的，针对用户同步的币串凭证，服务器验证通过后，将币串凭证的每个交易子链的子链数字签名保存到服务器的数据库中，其 中，不同冠字号的币串凭证可以保存到不同的交易树结构中，这些保存的数据将作为历史记录，在后续的验证过程中作为对比验证的参考值，即所有币串凭证在验证交易子链签名的过程中，在数据库的交易树结构中可以查询到的签名无需重复验证，只需对数据库中不存在的节点进行增量验证，并在验证成功后在交易树结构中追加已验证的节点，用于后续币串凭证的快速验证。
数字货币在流通的过程中，同一冠字号的币串凭证经过交易会被不断拆分和扩散，最终多个用户持有的币串凭证存在部分重复信息，在同步过程中将已验证的交易数据保存在特定的交易树结构中，使不同用户持有的币串凭证中的重复信息仅需要通过简单的数据比对即可验证，而不需要重复验证签名，减轻服务器侧数字签名验证的压力。
第四方面，针对本申请第一方面提供的方法，本申请实施例还提供一种交易验证的装置，该装置具有实现第一方面提供的任意一种方法的功能。这些功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块。该装置可以以芯片的产品形态存在。该交易验证的装置具体可以是第一电子设备，也可以是设置在第一电子设备上固定的或可移除的功能模块。
第五方面，针对本申请第二方面提供的方法，本申请实施例还提供一种交易验证的装置，该装置具有实现第二方面提供的任意一种方法的功能。这些功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块。该装置可以以芯片的产品形态存在。该交易验证的装置具体可以是第二电子设备，也可以是设置在第二电子设备上固定的或可移除的功能模块。
第六方面，针对本申请第三方面提供的方法，本申请实施例还提供一种交易验证的装置，该装置具有实现第三方面提供的任意一种方法的功能。这些功能可以通过硬件实现，也可以通过硬件执行相应的软件实现。该硬件或软件包括一个或多个与上述功能相对应的模块。该装置可以以芯片的产品形态存在。该交易验证的装置具体可以是服务器，也可以是设置在服务器上固定的或可移除的功能模块。
第七方面，本申请实施例提供一种电子设备，其特征在于，所述电子设备包括一个或多个处理器、存储器以及一个或多个计算机程序，其中所述一个或多个计算机程序被存储在所述存储器中，所述一个或多个计算机程序包括指令；当所述指令被所述一个或多个处理器执行时，使得所述电子设备执行第一方面的任意一种实现方式提供的方法；或者，当所述指令被所述一个或多个处理器执行时，使得所述电子设备执行第二方面的任意一种实现方式提供的方法。
第八方面，本申请实施例提供一种服务器，其特征在于，所述服务器包括一个或多个处理器、存储器以及一个或多个计算机程序，其中所述一个或多个计算机程序被存储在所述存储器中，所述一个或多个计算机程序包括指令；当所述指令被所述一个或多个处理器执行时，使得所述服务器执行第三方面的任意一种实现方式提供的方法。
第九方面，本申请实施例提供一种交易验证的系统，其特征在于，所述系统包括第一电 子设备、第二电子设备和服务器，所述第一电子设备用于执行第一方面所述方法的操作步骤，所述第二电子设备用于执行第二方面所述方法的操作步骤，所述服务器用于执行第三方面所述方法的操作步骤。
第十方面，本申请实施例提供一种存储介质，其特征在于，包括计算机程序，所述计算机程序当在一个或多个处理器上运行的时候用于实现第一方面的任意一种实现方式提供的方法；或者，所述计算机程序当在一个或多个处理器上运行的时候用于实现第二方面的任意一种实现方式提供的方法；或者，所述计算机程序当在一个或多个处理器上运行的时候用于实现第三方面的任意一种实现方式提供的方法。
第十一方面，本申请实施例提供一种计算机程序或计算机程序产品，其特征在于，当所述计算机程序或计算机程序产品在一个或多个处理器上运行的时候用于实现第一方面的任意一种实现方式提供的方法；或者，当所述计算机程序或计算机程序产品在一个或多个处理器上运行的时候用于实现第二方面的任意一种实现方式提供的方法；或者，当所述计算机程序或计算机程序产品在一个或多个处理器上运行的时候用于实现第三方面的任意一种实现方式提供的方法。
第十二方面，本申请实施例提供一种芯片系统，包括至少一个处理器和至少一个接口电路，至少一个接口电路用于执行收发功能，并将指令发送给至少一个处理器，当至少一个处理器执行指令时，至少一个处理器执行如上述第一方面至第三方面，以及其中任一种可能的实现方式提供的方法。
第四方面至第十二方面中任一种设计方式所带来的技术效果可参见第一方面、第二方面或第三方面中不同设计方式所带来的技术效果，此处不再赘述。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本申请实施例提供的数字货币验证的系统架构示意图；
图2为现有技术提供的币串凭证结构示意图；
图3为现有技术提供的终端设备的逻辑功能示意图；
图4为现有技术提供的端侧双离线交易的流程示意图；
图5为现有技术提供的云端服务器验证数字货币的方法的流程示意图；
图6为本申请实施例提供的币串凭证的结构示意图；
图7为本申请实施例提供的终端设备的逻辑功能示意图；
图8为本申请实施例提供的云侧发行机构的数字货币验证的逻辑结构示意图；
图9为本申请实施例提供的一种服务器存储币串凭证的数字签名的结构示意图；
图9a为本申请实施例提供的一种交易分支示意图；
图9b为本申请实施例提供的另一种交易分支示意图；
图10为本申请实施例提供的一种服务器验证数字货币的流程示意图；
图11为本申请实施例提供的一种端侧双离线交易的流程示意图；
图12为本申请实施例提供的一种第一电子设备的装置示意图；
图13为本申请实施例提供的一种第二电子设备的装置示意图；
图14为本申请实施例提供的一种服务器的装置示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
在本申请实施例的描述中，除非另有说明，“多个”的含义是两个或两个以上。本申请中的术语“和/或”或字符“/”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或，或A/B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。
在介绍本申请实施例之前，为了便于理解本申请实施例，先对现有技术中的数字货币验证的方式进行简单介绍。以下将以云侧系统为例，来说明上述服务器的功能；将以端侧系统为例，来说明上述电子设备的功能，其中，下文将以终端设备A作为第一电子设备、终端设备B作为第二电子设备为例进行描述，下文在描述交易子链的子链数字签名时将用交易子链的数字签名代替。
以下将以数字货币验证为例来说明交易验证的系统架构、流程等。
图1为本申请实施例提供的数字货币验证的系统架构示意图。
示例性的，本申请实施例的系统主要分为云侧系统和端侧系统两部分，云侧系统和端侧系统之间可以进行币串同步或者在线交易，其中：
云侧系统包括：
数字货币发行机构后台系统：用于本发行机构币串凭证的验证、同步等功能。图1中以发行机构A，发行机构B为例进行呈现，示例性的，发行机构可以为银行。
央行机构互联互通平台：将各货币发行机构通过央行联通，用于机构间的交易通信和央行对各机构的审计等工作，图2中发行机构A与发行机构B通过央行机构互联互通平台进行机构互联。
端侧系统包含终端设备安全钱包应用，图1中示例性的示出了终端设备A和终端设备B。可以理解的是，终端设备为电子设备的一种，电子设备包括但不限于：终端设备、固定电子设备、网络设备。其中，终端设备可以是移动终端设备、固定终端设备。电子设备可以是现有技术中的电子设备，也可以是未来出现的电子设备。
示例性的，本申请的实施例中的电子设备可以是可移动电话(mobile phone)、平板电脑(pad)、带无线收发功能的电脑、个人数字助理(personal digital assistant，PDA)、智能手表、上网本、可穿戴电子设备、增强现实技术(augmented reality，AR)设备、虚拟现实(virtual reality，VR)设备、车载设备、工业控制(industrial control)中的无线终端、无人驾驶(self driving)中的无线终端、远程医疗(remote medical)中的无线终端、智能电网(smart grid)中的无线终端、运输安全(transportation safety)中的无线 终端、智慧城市(smart city)中的无线终端、智慧家庭(smart home)中的无线终端、人工智能(artificial intelligence，AI)终端等。
本申请实施例提供了一种数字货币验证的方法，该方法可以应用于电子设备中。以下，将以终端设备作为电子设备的一种对本申请实施例进行描述。本申请实施例提供的技术方案可适用于具有富执行环境(Rich Execution Environment,REE)、可信执行环境(Trusted Execution Environment,TEE)和安全单元(Secure Element,SE)的终端设备:
富执行环境REE模块：也称为普通执行环境，是操作系统及其上层的各种应用的执行环境，例如，在终端设备上实现的客户端钱包应用程序，也称作软钱包，运行在终端设备REE环境中；
可信执行环境TEE模块：是基于ARM的TrustZone技术实现的，该技术在移动设备(包含智能手机、平板电脑、机顶盒、智能电视等)的主处理器上划出了一个安全区域，可以保证加载到该环境内部的代码和数据的安全性、机密性以及完整性。TEE提供的执行空间比常见的移动操作系统(如Linux、Android等)提供的空间具有更高级别的安全性。TEE通常用于运行关键的操作：(1)、移动支付：指纹验证、PIN码输入等；(2)、机密数据：私钥、证书等的安全存储；(3)、内容包括：DRM(数字版权保护)等。TEE可以为REE提供安全服务。
安全单元SE模块：是一种用于存储敏感数据和执行安全应用的微处理器芯片，可应用于身份认证、数字签名、安全存储等场景，是基于硬件的独立运行环境，不与宿主机器共享系统资源，安全级别最高。但是由于具有独立的运算单元，处理能力有限。通常的应用有运营商发放的SIM卡，一些安全公司的加密SD卡，或者内置在设备中的独立芯片模块。
端侧系统内不同的终端设备可以进行离线交易。以终端设备A与终端设备B之间进行双离线交易为例，双离线交易表示使用数字货币交易的双方均为离线状态下，仅通过终端设备传递币串凭证产生的交易，该交易会在原币串凭证末尾追加新的交易子链，新的交易子链会标记本次交易金额，末尾交易子链的金额表示了新币串凭证的价值。
基于图1所示的系统架构，下面介绍现有技术中的数字货币的数字签名的生成和验证的流程。
如图2所示，为现有技术中的币串凭证的结构示意图。
具体的，原始币串包含货币发行时的金额、货币发行机构、冠字号等必要信息，并由货币发行机构对其进行签名；随着货币的流通，会不断在末尾追加交易子链，并在每次交易的末尾对全量数据进行签名。货币的数字凭证结构由原始币串与交易子链组成序列结构，凭证传递都会产生新的交易子链，并添加数字签名保证数据完整性和有效性。
示例性的，如图2所示，在原始币串的基础上，当进行一次交易后，端侧根据原始币串的数据以及本次交易的数据生成的数字签名1，用以说明交易子链1的合法性，其中，交易1和数字签名1构成交易子链1。当发生第二次交易后，则根据原始币串、交易子链1第二次交易相关的数据生成数字签名2，用以说明交易子链2的合法性，其中，交易子链1包含数字签名1，交易2和数字签名2构成交易子链2。以此类推。
现有技术中，每次生成数字签名都需要对所有前序交易数据进行整体签名，因此，在对币串凭证生成数字签名过程中存在冗余的摘要计算。在这种实现下，由于币串凭证交易子链的签名方式为对全量数据进行签名，因此在对币串凭证进行验证过程中需要逐层验证数字签名，在验证数字签名过程中的摘要计算流程也存在冗余计算。
如图3所示，为现有技术的终端设备的逻辑功能示意图。
具体的，在数字货币场景下，终端设备的硬钱包逻辑主要在SE侧的Applet应用程序实现，其中定义了硬钱包交易流程必要的接口和数据。主要的接口功能包括：余额查询，币串同步，转入转出，币串验证等；主要的数据包括用户秘钥，数字货币币串凭证，交易记录，机构证书等，其中，用户秘钥用于标识交易双方身份。
TEE仅用来存储简单的用户标识信息如指纹密码、人脸、通讯秘钥等，其中，通讯秘钥用于设备间通信时信道的加密。
下文以转账交易为例进行说明，涉及付款、收款业务流程。
如图4所示，为现有技术的端侧双离线交易的流程示意图，具体步骤如下：
步骤S401-S402：付款方用户在REE软钱包发起付款请求，REE生成与SE交互的付款指令；
步骤S403：付款方SE接收到付款指令后执行相应的逻辑准备交易，例如余额验证；
步骤S404-S405：付款方SE在币串凭证末尾拼接交易子链产生新的币串凭证，将币串凭证返回给REE；
步骤S406：付款方REE根据新的币串凭证生成收款指令后，发给收款方；
步骤S407：收款方REE透传收款指令到SE；
步骤S408-S409：收款方SE验证币串凭证，验证通过后将币串凭证保存到本地；
步骤S410-S412：收款方返回交易确认信息，付款方接收后完成交易。
如图5所示，为现有技术提供的云端服务器验证数字货币的方法的流程示意图。具体步骤如下：
步骤S501：终端用户连接发行机构服务器，并上传带有N个交易子链的币串凭证，以及与该币串相关的余额和交易流水数据；
步骤S502-S506：云端服务器解析币串凭证数据，在币串凭证中从后往前提取交易子链的数字签名，并依次使用相应的签名算法如国密算法进行验证；
步骤S507-S508：当所有的交易子链的签名都验证通过后，提取原始币串的机构签名和原始币串数据，通过原始币串的机构签名和原始币串数据验证原始币串的合法性；若原始币串的机构签名验证不成功，则该验证流程失败，如步骤S511所示，流程结束。
步骤S509-S510：原始币串的机构签名验证通过后，验证余额和流水的有效性，如果验证成功则币串凭证有效，验证流程结束。
如上描述的现有技术能够有效实现数字货币在线、离线交易的功能，解决离线币串凭证的合法性和安全性问题，然而仍然存在验证过程中存在一定的冗余计算以及受限于性能用户体验较差的不足。这些不足的产生原因如下：
从端侧分析：币串凭证每次传递都会追加一个交易子链，每次追加都需要对所有的凭证数据进行数字签名，给端侧的签名验证带来压力。终端设备的硬钱包逻辑主要在SE中实现，TEE仅用来存储简单的用户标识信息如指纹、人脸等。终端SE为硬件隔离的独立运行环境，存储空间与计算性能受限。端侧TEE的安全略性低于SE，但性能要远高于SE，当前绝大部分的业务逻辑都在SE中实现，TEE中仅实现简单功能，没有充分利用性能。
从服务器侧分析：在服务端验证币串凭证过程中，由于币串凭证交易子链的签名方式为对全量数据进行签名，因此验证过程中需要逐层验证签名，在验签过程中的摘要计算流程存在冗余计算；同时，在数字货币流通过程中，相同冠字号币串会扩散到不同的用户终端中，不同用户的币串凭证中必然存在一定的重复信息，不同用户上传的币串凭证后存在重复的交易子链签名验证。
针对上述问题，本申请实施例提供一种数字货币验证的方法，该方法基于图1所示的系统架构，该方法主要包括如下技术点：
1、对币串凭证的数字签名采用链式结构：随着交易的进行，每次交易会产生交易子链，其中，每一个交易子链中的数字签名为根据前一次交易的签名结果与本次交易数据生成的数字签名，即Signature(n)＝Sign(Signature(n-1)+transaction(n))，其中，Signature(n-1)标识本次交易的前一次交易生成的数字签名，transaction(n)表示本次交易相关的信息。可以理解的是，这种签名方式下将形成一条增量的链式签名结构。
2、由于币串凭证的链式结构，最后一个交易子链的数字签名可以验证币串凭证整体信息的完整性和合法性。由此，在端侧交互过程中，将SE侧的业务逻辑转移至TEE侧执行，将保证交易合法性数字签名验证过程保留在SE中。
3、云服务器侧接收到端侧同步的币串凭证后，构建币串凭证交易树，以树形结构保存验证通过的交易子链的数字签名，在验证过程中，对交易子链的数字签名进行增量验证，所有币串凭证在验证交易子链签名的过程中，在数据库的交易树结构中可以查询到的签名无需重复验证，只需对数据库中不存在的节点进行增量验证，并在验证成功后在交易树结构中追加已验证的节点，用于后续币串凭证的快速验证。
如图6所示，为本申请实施例提供的币串凭证的结构示意图。
随着交易的进行，每次交易会产生交易子链，其中，每一个交易子链中的数字签名为根据前一次交易的签名结果与本次交易数据生成的数字签名，即Signature(n)＝Sign(Signature(n-1)+transaction(n))，其中，Signature(n-1)标识本次交易的前一次交易生成的数字签名，transaction(n)表示本次交易相关的信息。可以理解的是，这种签名方式下将形成一条增量的链式签名结构。
示例性的，如图6所示，在原始币串的基础上，当进行一次交易后，端侧根据原始币串的数据以及本次交易的数据生成的数字签名1，用以说明交易子链1的合法性，其中，交易1和数字签名1构成交易子链1。当发生第二次交易后，则根据数字签名1和第二次交易相关的数据生成数字签名2，用以说明交易子链2的合法性，其中，交易2和数字签名2构成交易子链2，以此类推。
这里为了方便描述链式签名的原理，将交易子链中的数字签名、原始币串中的机构签名单独呈现出来。实现过程中，交易子链可以包含数字签名，原始币串可以包含机构签名。
用链式签名方案替代整体签名方案，在对币串凭证生成数字签名和验证数字签名的过程中减少了冗余的摘要计算，提高端侧币串凭证生成和验证的性能，提升端侧用户体验，同时保证了整体凭证的合法性和完整性。
如图7所示，为本申请实施例提供的终端设备的逻辑功能示意图。
示例性的，终端设备包括富执行环境(REE)、可信执行环境(TEE)和安全单元(SE)。
在终端设备中，可信执行环境TEE中实现了数字货币交易流程中的大部分逻辑，包括余额查询、币串同步、转入转出等，同时还保存了指纹密码、通讯秘钥、机构证书、数字货币币串、交易记录等。TEE的计算性能和存储空间都要优于SE，因此可以充分利用端侧的性能，提升用户体验。
安全单元SE中定义了硬钱包交易流程中必要的接口和数据两方面：接口主要为验证币串凭证末尾交易子链的数字签名，用于收款方验证传入币串凭证的合法性；数据主要为币串凭证末尾交易子链的数字签名，用于付款方交易前保证TEE侧的币串没有被篡改。当付款方TEE的币串凭证数据发生篡改时，末末尾交易子链的数字签名也会发生改变，传入SE后发现与SE中收到此币串凭证时存储的数字签名不一致，则验证失败。当收款方收到合法的币串凭证时，将在SE中验证末尾交易子链的数字签名，数字签名验证成功后会在SE中存储该币串凭证对应的末尾交易子链的数字签名。因此，交易的安全性依旧由SE保证，但性能通过使用TEE获得了大幅提升。
如图8所示，为本申请实施例提供的云侧发行机构的数字货币验证的逻辑结构示意图。
在发行结构中，各逻辑模块的功能如下：
币串凭证解析：从用户上传的数据中解析币串凭证各部分的内容，主要提取机构签名与交易子链的数字签名；
数字签名校验：根据本发明方案中的链式签名方法，验证币串凭证上所有数字签名的合法性，并将已验证的数字签名保存到交易树的存储结构中；
交易树存储：数字货币在上传至发行机构后台时，每一个唯一的冠字号都会生成一个表示数字签名信息的节点组成的树形结构，从树根到某一个叶节点的遍历路径代表了一个币串凭证的交易链，多个持有同一冠字号币串的用户同步操作之后，形成的树形结构表示了该原始币串的整个流通传递过程。
冠字号查询：在发行机构后台的存储中，根据币串凭证的冠字号查询相应的验证数据，即该冠字号关联的交易树；
数字签名对比：遍历币串凭证中的数字签名数据，与已验证通过的交易树节点做对比，若找到未验证的节点，则对这些节点进行增量验证。
如图9所示，为本申请实施例提供的一种服务器存储币串凭证的数字签名的结构示意图。
由于币串凭证的传递机制，数字货币流通过程中，同一冠字号的币串凭证会形成如图9所示的拓扑结构。其中数字签名x-n表示付款方x使用该币串凭证第n次付款交易产生的数字签名，使用了付款方x的私钥。
当多个用户同步币串凭证在服务器端验证币串凭证有效性时，在数据库中构建并存储如图树形结构，每个节点为相应交易子链的数字签名值，父节点与子节点的关系由之前币串凭证定义的链式签名方式决定。
示例性的，具体的增量验证方法如下：
以币串凭证经过A、B、C、D用户为例：A->B->D->F，用户D和用户F分别先后在线同步币串凭证到云侧服务器。
如图9a所示，为本申请实施例提供的一种交易分支示意图。
用户D同步币串凭证后形成如图9a的交易分支，其中连线b表示用户A向用户B付款的 交易，连线d表示用户B向用户D付款的交易。当此交易分支第一次生成时，需要进行完整的合法性校验，校验内容包括：原始币串的机构签名，根据交易子链b的内容和机构签名验证数字签名A-1，根据交易子链d的内容和数字签名A-1验证数字签名B-1；同理，若交易子链更长，签名可迭代验证。
如图9b所示，为本申请实施例提供的另一种交易分支示意图。用户F同步币串凭证后形成如图9b的交易分支，其中通过简单的签名值对比可以确认交易分支b和d均已通过用户D上传的币串凭证验证完成且合法，用户F的数字签名验证只需验证用户D付款给用户F的交易f与数字签名D-1。
在上述架构示意图以及币串凭证结构示意图的基础上，下面将以两个具体的实施例进行详细描述。
如图10所示，为本申请实施例提供一种的服务器验证数字货币的流程示意图，该方法可以包括步骤S1001-步骤S1010，具体如下：
步骤S1001：用户在同步过程中上传币串凭证到发行机构服务器。
本步骤用户需要将钱包中需要同步的币串凭证根据原始币串中的信息上传到相应的发行机构进行验证。这里描述的原始币串的信息可以包括发行机构标识、币串金额、机构证书、机构保留字段等。在本步骤中每个币串凭证需要携带完整的信息包括：原始币串金额、发信机构证书、发行机构签名、每次交易产生的交易子链，其中每个交易子链中还包括：交易金额、交易信息包括交易索引、付款方公钥、付款方签名等。我们将一个币串凭证的交易子链数声明为N。
步骤S1002：根据币串冠字号查询相应的验证数据。
本步骤在具体验证币串凭证的数字签名前执行，首先从币串凭证中提取冠字号信息，然后在数据库中查询该冠字号是否有已验证的记录。
如果没有记录，则执行步骤S1009-S1010，即将以与现有方案一致的方式逐个交易子链验证数字签名，具体流程见图5，然后将每个交易子链的数字签名数据作为节点构建成一条从原始币串的机构签名开始的分支结构，用于后续币串凭证的快速验证，至此，流程结束；
若存在已验证的记录，则执行步骤S1003-S1008：
步骤S1003：将本币串凭证的数字签名与分支节点存储的已验证的数字签名对比，本步骤需要从原始币串的机构签名开始遍历币串凭证的数字签名数据，并与已验证分支的节点数据比较；
步骤S1004：判断是否存在不一致的节点：若存在数据不一致的节点，则该币串凭证验证失败，流程结束；否则，执行步骤S1005-S1008。
步骤S1005-S1008：获取已验证的交易子链数M：
若M>＝N，则币串凭证的所有交易子链的数字签名均一致，则该币串凭证有效，验证成功，流程结束；
若M<N，说明币串凭证仍然存在未验证的交易子链的数字签名，则迭代验证剩余交易子链的数字签名，然后将验证成功的交易子链的数字签名保存在追加的分支节点上，用于后续币串凭证的快速验证。所有的数字签名验证有效后，则证明币串凭证有效，可进行其他的验证流程，如流水验证、余额验证等。
如图11所示，为本申请实施例提供端侧双离线交易的流程示意图。该流程包含离线交易 的两个终端设备之间的流程示意图。实际应用过程中，还包含其他场景，比如在线流程，单离线流程(包括付款方在线收款方离线，或者付款方离线收款方在线)，可以理解的是，当实际应用场景为单离线流程时，付款方或者收款方的流程在本地的处理分别与双离线流程中付款方或者收款方的处理相同。
具体步骤如下：
步骤S1101：用户在REE侧的钱包App操作，发起付款请求。
本步骤中付款方用户根据其他渠道协商收款方的目标地址，按照相应的TEE接口向TEE发送付款请求。
步骤S1102：付款方TEE读取TEE中存储的币串凭证，生成付款指令。
本步骤中TEE会根据付款金额选择合适的币串，经过TEE中的基本验证后提取币串凭证末尾的数字签名，将该数字签名传入SE。其中，基本验证包括验证交易金额是否合法；或初始化设置的限额信息如钱包限额，交易次数，交易限额等是否合法，这些限额信息可以保存到TEE或者SE中，若是保存到SE中，则可以从SE读取到TEE中，由TEE进行验证。交易次数可以通过交易子链个数或者币串凭证长度来判断。
步骤S1103：付款方SE执行付款指令逻辑；
步骤S1104：付款方SE将接收到的来自TEE的数字签名与上一次交易验证通过后保存的末尾交易子链的数字签名做对比，如果本次交易的末尾交易子链的数字签名与SE中的数字签名一致，则可证明TEE中的币串数据没有被篡改，因为SE中存储的末尾交易子链的数字签名从上一次交易完成后没有在SE中被更改。
步骤S1105-S1106：付款方SE生成新的交易子链，并将新的交易子链返回给付款方TEE。
本步骤根据付款方本次交易需要的交易金额以及随机数或其他保留字段生成交易子链数据，并根据上次交易的末尾交易子链的数字签名以及本次交易子链的数据，生成新的交易签名，最后将交易信息和数字签名拼接成新的交易子链返回给TEE，其中所述SE根据所述交易金额生成交易信息。
步骤S1107：付款方TEE将SE返回的新交易子链拼接到原有的币串凭证上，生成收款指令发送给收款方。
步骤S1108：收款方REE透传收款请求到TEE，TEE收到收款请求后执行收款逻辑，并从收款请求中提取出币串凭证的所有数据。
步骤S1109-S1113：收款方在TEE和SE协同验证币串凭证。
本申请传递的是验证签名指令：仅包含末尾签名；现在仅保存了新生成的币串签名。
现有技术的指令为收款指令，包含了整个币串；原先SE保存了整个币串。
本步骤中收款方在TEE中执行大部分的币串验证逻辑，包括原始币串的机构签名验证、余额验证，以及交易子链的数字签名验证。当验证到末尾交易子链的数字签名时，将末尾签名验证所必要的信息通过验证指令传入SE中进行验证，其中，末尾签名验证所必要的信息包括倒数第二个交易子链的数字签名、末尾交易子链的信息、末尾交易子链的数字签名。SE中验证通过后，在SE中保存末尾交易子链的数字签名用于后续交易的付款前对比验证，同时将验证结果返回给TEE。TEE确认验证结果，并将新的币串凭证存储在TEE本地，验证成功后向付款方发送确认信息。
步骤S1114-S1115：付款方接收确认信息，对确认信息进行验证后完成交易。在币串的金额使用完的情况下，对币串标记删除币串标识，后续将币串凭证同步到服务器时由服务器根据该标识将币串凭证删除。可以理解的是，这里的确认信息为上述发明内容中的第二交易 响应消息的一种示例。
以上为对本申请实施例提供的数字货币验证的方法的详细说明。
上述主要从方法的角度对本申请实施例的方案进行了介绍。可以理解的是，数字货币验证装置为了实现上述功能，其包含了执行各个功能相应的硬件结构和/或软件模块。本领域技术人员应该很容易意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，本申请能够以硬件或硬件和计算机软件的结合形式来实现。某个功能究竟以硬件还是计算机软件驱动硬件的方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。
本申请实施例可以根据上述方法示例对数字货币验证装置进行功能单元的划分，例如，可以对应各个功能划分各个功能单元，也可以将两个或两个以上的功能集成在一个处理单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。需要说明的是，本申请实施例中对单元的划分是示意性的，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式。
在一个示例中，当对应各个功能划分各个功能单元时，如图12所示，为本申请实施例提供的一种第一电子设备的装置示意图。所述装置1200包括富执行环境REE模块1201、可信执行环境TEE模块1202、安全单元SE模块1203：
所述富执行环境REE模块1201用于：向所述执行环境TEE模块发送第一交易请求消息，所述第一交易请求消息包括交易的交易类型和交易接收方标识；
所述可信执行环境TEE模块1202用于：根据所述交易类型执行第一业务逻辑以获得第一验证指令，向所述安全单元SE模块1203发送所述第一验证指令，所述第一验证指令包含数字签名；
所述安全单元SE模块1203用于：根据所述数字签名验证所述交易的合法性以获得第一验证结果，并将第一验证结果发送给所述可信执行环境TEE模块；
所述可信执行环境TEE模块1202还用于：发送第一交易响应消息给所述富执行环境REE模块，所述第一交易响应消息包含所述第一验证结果；
所述富执行环境REE模块1203还用于：根据所述接收方标识发送第二交易请求消息给第二电子设备。
一种可能的设计，所述可信执行环境TEE模块1202还用于保存至少一个数据凭证；根据所述交易类型以及所述至少一个数据凭证执行所述第一业务逻辑。
一种可能的设计，所述数据凭证包括币串凭证，所述币串凭证包括原始币串或者原始币串以及至少一个交易子链，所述交易子链包括数字签名，所述数字签名用于指示所述交易子链的合法性，所述原始币串包括原始币串金额、发行机构证书、发行机构签名。
一种可能的设计，所述第一交易请求消息还包括交易金额；所述可信执行环境TEE模块1202具体用于：根据所述交易类型以及所述交易金额从所述至少一个币串凭证中选择至少一个币串凭证；对选择的所述至少一个币串凭证进行基本验证，所述基本验证包括交易次数或交易限额验证；基本验证通过后，提取所述至少一个币串凭证中每个币串凭证的最后一个交易子链的数字签名，生成包括所述每一个币串凭证的最后一个交易子链的数字签名和所述交易金额的第一验证指令。
一种可能的设计，所述币串凭证包括冠字号，所述冠字号为所述币串凭证的唯一标识；所述安全单元SE模块1203具体用于：根据所述第一验证指令中的所述交易金额生成交易信息；根据所述冠字号将本地存储的签名与所述第一验证指令中的所述最后一个交易子链的数字签名进行对比，当所述本地存储的签名与所述第一验证指令中的最后一个交易子链的数字签名一致时，根据所述交易信息、所述最后一个交易子链的数字签名和本地保存的私钥生成第二数字签名；根据所述第二数字签名和所述交易信息生成新的交易子链；生成包括所述新的交易子链的第一验证结果。
一种可能的设计，所述可信执行环境TEE模块1202具体用于根据冠字号将所述新的交易子链更新到所述币串凭证上。
一种可能的设计，所述富执行环境REE模块1203还用于将所述数据凭证同步到服务器。
如图13所示，为本申请实施例提供的一种第二电子设备的装置示意图。该装置1300包括富执行环境REE模块1301、可信执行环境TEE模块1302和安全单元SE模块1303：
所述富执行环境REE模块1301用于：接收来自第一电子设备的第二交易请求消息，并将所述第二交易请求消息发送给所述可信执行环境TEE模块1302，所述第二交易请求消息包含至少一个数据凭证，其中，所述数据凭证包括冠字号，所述冠字号为所述数据凭证的唯一标识；
所述可信执行环境TEE模块1302用于：根据所述至少一个数据凭证执行第二业务逻辑以获得第二验证指令，向所述安全单元SE模块1303发送所述第二验证指令，所述第二验证指令包括数字签名；
所述安全单元SE模块1303用于：根据所述数字签名验证所述至少一个数据凭证的合法性以获得第二验证结果，并将所述第二验证结果发送给所述可信执行环境TEE模块1302，所述第二验证结果指示所述至少一个数据凭证的合法性是否验证通过；
所述可信执行环境TEE模块1302还用于：接收来自所述安全单元SE模块1303的所述第二验证结果，保存所述验证通过的数据凭证，发送第二交易响应消息给所述富执行环境REE模块1301，所述第二交易响应消息用于指示交易是否成功；
所述富执行环境REE模块1301还用于：发送第二交易响应消息给第一电子设备。
一种可能的设计，所述数据凭证包括币串凭证，所述币串凭证包括原始币串或者原始币串以及至少一个交易子链，所述交易子链包括数字签名，所述数字签名用于指示所述交易子链的合法性，所述原始币串包括原始币串金额、发行机构证书、发行机构签名。
一种可能的设计，所述第二业务逻辑包括原始币串的机构签名验证或所述币串凭证的最后一个交易子链的前序交易的验证。
一种可能的设计，所述安全单元SE模块1303具体用于验证所述至少一个数据凭证的每个数据凭证的最后一个交易子链的合法性。
一种可能的设计，所述安全单元SE模块1303还用于所述最后一个交易子链的合法性验证通过后，保存所述最后一个交易子链的数字签名，所述数字签名用于后续交易时作为对比验证的参考值。
如图14所示，为本申请实施例提供的一种服务器的装置示意图。该装置1400包括：
接收模块1401，用于接收来自电子设备的数据凭证；
验证模块1402，用于对所述数据凭证进行增量验证，所述增量验证包括将所述数据凭证与保存在所述服务器的历史记录进行对比，验证所述数据凭证中比所述历史记录多余的数据 的合法性，其中，所述历史记录为已验证的历史数据凭证；
保存模块1403，用于保存验证成功的所述数据凭证。
一种可能的设计，所述数据凭证包括币串凭证，所述币串凭证包括原始币串或者原始币串以及至少一个交易子链，其中，所述原始币串包括原始币串金额、发行机构证书和发行机构签名，所述交易子链包括交易金额、交易信息、公钥和数字签名，所述数字签名为根据前一次交易的签名结果与本次交易数据生成的数字签名。
一种可能的设计，所述币串凭证包括冠字号，所述冠字号为所述币串凭证的唯一标识；所述验证模块1402具体用于根据冠字号查询所述服务器是否存在与所述冠字号对应的历史币串凭证，当所述服务器存在与所述币串凭证具有相同冠字号的历史币串凭证时，遍历所述币串凭证的交易子链，验证所述币串凭证中比所述历史币串凭证多出的未验证的交易子链。
一种可能的设计，所述验证模块1402具体用于当所述服务器不存在与所述币串凭证具有相同冠字号的历史币串凭证时，对所述币串凭证中的所有交易子链进行验证。
一种可能的设计，所述验证模块1402具体用于验证数字签名、发行机构签名、余额和交易流水。
一种可能的设计，所述保存模块1403具体用于根据冠字号将已验证的所述交易子链的数字签名作为特征数据存储到所述服务器。
装置实施例中涉及到的方案的具体实现可参考前述方法实施例，在此不再赘述。
当将以上的多个功能单元(或模块)集成在一个处理单元中时，上述各个功能单元执行的动作均可由处理单元根据存储单元中存储的程序执行。其中，处理单元可以是处理器或控制器。存储单元可以是存储器。当处理单元为处理器，存储单元为存储器时，上述各个功能单元执行的动作可以由处理器根据存储器中存储的程序执行。
本申请实施例还提供了一种计算机可读存储介质，包括指令，当其在计算机上运行时，使得计算机执行上述方法。
本申请实施例还提供了一种包含指令的计算机程序或计算机程序产品，当其在计算机上运行时，使得计算机执行上述方法。
在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件程序实现时，可以全部或部分地以计算机程序产品的形式来实现。该计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，计算机指令可以从一个网站站点、计算机、服务器或者数据中心通过有线(例如同轴电缆、光纤、数字用户线(digital subscriber line，简称DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可以用介质集成的服务器、数据中心等数据存储设备。可用介质可以是磁性介质(例如，软盘、硬盘、磁带)，光介质(例如，DVD)、或者半导体介质(例如固态硬盘(solid state disk，简称SSD))等。
尽管在此结合各实施例对本申请进行了描述，然而，在实施所要求保护的本申请过程中，本领域技术人员通过查看附图、公开内容、以及所附权利要求书，可理解并实现公开实施例 的其他变化。在权利要求中，“包括”(comprising)一词不排除其他组成部分或步骤，“一”或“一个”不排除多个的情况。单个处理器或其他单元可以实现权利要求中列举的若干项功能。相互不同的从属权利要求中记载了某些措施，但这并不表示这些措施不能组合起来产生良好的效果。
尽管结合具体特征及其实施例对本申请进行了描述，显而易见的，在不脱离本申请的精神和范围的情况下，可对其进行各种修改和组合。相应地，本说明书和附图仅仅是所附权利要求所界定的本申请的示例性说明，且视为已覆盖本申请范围内的任意和所有修改、变化、组合或等同物。

Claims (40)

  1. 一种交易验证的方法，其特征在于，所述方法应用于包括安全单元SE、可信执行环境TEE和富执行环境REE的第一电子设备，所述方法包括：
    所述REE向所述TEE发送第一交易请求消息，所述第一交易请求消息包括交易的交易类型；
    所述TEE根据所述交易类型执行第一业务逻辑以获得第一验证指令，所述第一验证指令包括待验证的数字签名；
    所述TEE向所述SE发送所述第一验证指令；
    所述SE根据所述待验证的数字签名验证所述交易的合法性以获得第一验证结果，并将所述第一验证结果发送给所述TEE；
    所述TEE发送第一交易响应消息给所述REE，所述第一交易响应消息包含所述第一验证结果；
    所述REE在所述第一验证结果指示验证成功时，根据所述交易的接收方标识向第二电子设备发送第二交易请求消息，所述接收方标识用于指示所述第二电子设备。
  2. 根据权利要求1所述的方法，其特征在于，
    所述TEE保存了至少一个候选的数据凭证；
    所述TEE根据所述交易类型执行第一业务逻辑包括：
    所述TEE根据所述交易类型以及所述至少一个候选的数据凭证执行所述第一业务逻辑。
  3. 根据权利要求2所述的方法，其特征在于，所述数据凭证包括币串凭证，所述币串凭证包括原始币串或者原始币串以及至少一个交易子链，所述原始币串包括原始币串金额、发行机构证书、发行机构签名，所述交易子链包括与所述交易子链对应的子链数字签名。
  4. 根据权利要求3所述的方法，其特征在于，所述第一交易请求消息还包括所述交易的交易金额；
    所述TEE根据所述交易类型以及所述至少一个候选的数据凭证执行所述第一业务逻辑包括：
    所述TEE根据所述交易类型以及所述交易金额从所述至少一个候选的币串凭证中选择待验证的币串凭证；
    所述TEE对所述待验证的币串凭证进行基本验证，所述基本验证包括交易次数或交易限额验证；
    所述TEE提取通过所述基本验证的币串凭证的最后一个交易子链的子链数字签名，生成所述第一验证指令，所述通过所述基本验证的币串凭证的最后一个交易子链的子链数字签名为所述待验证的数字签名，所述第一验证指令包括通过所述基本验证的币串凭证的最后一个交易子链的子链数字签名和所述交易金额。
  5. 根据权利要求4所述的方法，其特征在于，所述通过所述基本验证的币串凭证包括冠字号，所述冠字号为所述通过所述基本验证的币串凭证的唯一标识；
    所述SE根据所述待验证的数字签名验证所述交易的合法性以获得第一验证结果包括：
    所述SE根据所述第一验证指令中的所述交易金额生成交易信息；
    所述SE根据所述冠字号将本地存储的参考数字签名与所述第一验证指令中的所述最后一个交易子链的子链数字签名进行对比，当所述本地存储的参考数字签名与所述第一验证指令中的最后一个交易子链的子链数字签名一致时，所述SE根据所述交易信息、所述最后一个交易子链的子链数字签名和所述SE本地保存的私钥生成与所述交易对应的数字签名；
    所述SE根据所述与所述交易对应的数字签名和所述交易信息生成与所述交易对应的交易子链，所述与所述交易对应的交易子链中的子链数字签名为所述与所述交易对应的数字签名；
    所述SE生成包括所述与所述交易对应的交易子链的第一验证结果。
  6. 根据权利要求5所述的方法，其特征在于，所述TEE保存所述第一验证结果；
    所述TEE根据所述冠字号将所述与所述交易对应的交易子链更新到所述通过所述基本验证的币串凭证上。
  7. 根据权利要求6所述的方法，其特征在于，所述方法还包括：
    所述第一电子设备将所述更新后的所述通过所述基本验证的币串凭证同步到服务器。
  8. 一种交易验证的方法，其特征在于，所述方法应用于包括安全单元SE、可信执行环境TEE和富执行环境REE的第二电子设备，所述方法包括：
    所述REE接收来自第一电子设备的第二交易请求消息，并将所述第二交易请求消息发送给所述TEE，所述第二交易请求消息包含至少一个数据凭证；
    所述TEE根据所述至少一个数据凭证执行第二业务逻辑以获得第二验证指令，所述第二验证指令包括待验证的数字签名；
    所述TEE向所述SE发送所述第二验证指令；
    所述SE根据所述待验证的数字签名验证所述至少一个数据凭证的合法性以获得第二验证结果，并将所述第二验证结果发送给所述TEE，所述第二验证结果指示所述至少一个数据凭证的合法性是否验证通过；
    所述TEE接收来自所述SE的所述第二验证结果，保存所述验证通过的数据凭证，发送第二交易响应消息给所述REE，所述第二交易响应消息用于指示交易是否成功；
    所述REE发送第二交易响应消息给第一电子设备。
  9. 根据权利要求8所述的方法，其特征在于，所述数据凭证包括币串凭证，所述币串凭证包括原始币串或者原始币串以及至少一个交易子链，所述原始币串包括原始币串金额、发行机构证书、发行机构签名，所述交易子链包括与所述交易子链对应的子链数字签名。
  10. 根据权利要求9所述的方法，其特征在于，所述第二业务逻辑包括原始币串的机构签名验证或所述币串凭证的最后一个交易子链的前序交易的验证。
  11. 根据权利要求9所述的方法，其特征在于，所述SE根据所述待验证的数字签名验证所述至少一个数据凭证的合法性以获得第二验证结果包括：
    验证所述至少一个币串凭证中的每个币串凭证的最后一个交易子链的合法性。
  12. 根据权利要求11所述的方法，其特征在于，所述方法还包括：
    所述最后一个交易子链的合法性验证通过后，所述SE保存所述最后一个交易子链的子链数字签名，所述最后一个交易子链的子链数字签名用于后续交易时作为对比验证的参考值。
  13. 一种交易验证的方法，其特征在于，所述方法应用于服务器，包括：
    接收来自电子设备的数据凭证；
    对所述数据凭证进行增量验证，所述增量验证包括将所述数据凭证与保存在所述服务器的历史数据凭证进行对比，验证所述历史数据凭证没有记录的所述数据凭证中的数据的合法性；
    保存所述合法性验证成功的所述数据凭证。
  14. 根据权利要求13所述的方法，其特征在于，所述数据凭证包括币串凭证，所述币串凭证包括原始币串或者原始币串以及至少一个交易子链，其中，所述原始币串包括原始币串金额、发行机构证书和发行机构签名，所述交易子链包括交易金额、交易信息、公钥和子链数字签名，所述子链数字签名为根据前一次交易对应的数字签名与本次交易数据生成的数字签名。
  15. 根据权利要求14所述的方法，其特征在于，所述币串凭证包括冠字号，所述冠字号为所述币串凭证的唯一标识；
    将所述币串凭证与保存在所述服务器的历史币串凭证进行对比包括：
    根据所述冠字号查询所述服务器是否存在与所述冠字号对应的历史币串凭证，当所述服务器存在与所述币串凭证具有相同冠字号的历史币串凭证时，遍历所述币串凭证的交易子链，验证所述币串凭证中比所述历史币串凭证多出的未验证的交易子链。
  16. 根据权利要求14所述的方法，其特征在于，所述方法还包括当所述服务器不存在与所述币串凭证具有相同冠字号的历史币串凭证时，对所述币串凭证中的所有交易子链进行验证。
  17. 根据权利要求15或16所述的方法，其特征在于，所述对交易子链进行验证包括验证子链数字签名、发行机构签名、余额和交易流水。
  18. 根据权利要求17所述的方法，其特征在于，所述保存验证成功的所述数据凭证包括根据所述冠字号将已验证的所述交易子链的子链数字签名作为特征数据存储到所述服务器。
  19. 一种第一电子设备，其特征在于，所述第一电子设备包括富执行环境REE模块、可信执行环境TEE模块、安全单元SE模块：
    所述富执行环境REE模块用于：向所述执行环境TEE模块发送第一交易请求消息，所述第一交易请求消息包括交易的交易类型；
    所述可信执行环境TEE模块用于：根据所述交易类型执行第一业务逻辑以获得第一验证指 令，向所述安全单元SE发送所述第一验证指令，所述第一验证指令包含数字签名；
    所述安全单元SE模块用于：根据所述数字签名验证所述交易的合法性以获得第一验证结果，并将第一验证结果发送给所述可信执行环境TEE模块；
    所述可信执行环境TEE模块还用于：发送第一交易响应消息给所述富执行环境REE模块，所述第一交易响应消息包含所述第一验证结果；
    所述富执行环境REE模块还用于：在所述第一验证结果指示验证成功时，根据所述交易的接收方标识向第二电子设备发送第二交易请求消息，所述接收方标识用于指示所述第二电子设备。
  20. 根据权利要求19所述的第一电子设备，所述可信执行环境TEE模块还用于：
    保存至少一个候选的数据凭证；
    根据所述交易类型以及所述至少一个候选的数据凭证执行所述第一业务逻辑。
  21. 根据权利要求20所述的第一电子设备，其特征在于，所述数据凭证包括币串凭证，所述币串凭证包括原始币串或者原始币串以及至少一个交易子链，所述原始币串包括原始币串金额、发行机构证书、发行机构签名，所述交易子链包括与所述交易子链对应的子链数字签名。
  22. 根据权利要求21所述的第一电子设备，其特征在于，所述第一交易请求消息还包括所述交易的交易金额；
    所述可信执行环境TEE模块具体用于：
    根据所述交易类型以及所述交易金额从所述至少一个候选的币串凭证中选择待验证的币串凭证；
    对所述待验证的币串凭证进行基本验证，所述基本验证包括交易次数或交易限额验证；
    提取通过所述基本验证的币串凭证的最后一个交易子链的子链数字签名，生成所述第一验证指令，所述通过所述基本验证的币串凭证的最后一个交易子链的子链数字签名为所述待验证的数字签名，所述第一验证指令包括通过所述基本验证的币串凭证的最后一个交易子链的子链数字签名和所述交易金额。
  23. 根据权利要求22所述的第一电子设备，其特征在于，所述通过所述基本验证的币串凭证包括冠字号，所述冠字号为所述通过所述基本验证的币串凭证的唯一标识；
    所述安全单元SE模块具体用于：
    根据所述第一验证指令中的所述交易金额生成交易信息；
    根据所述冠字号将本地存储的参考数字签名与所述第一验证指令中的所述最后一个交易子链的子链数字签名进行对比，当所述本地存储的参考数字签名与所述第一验证指令中的最后一个交易子链的子链数字签名一致时，根据所述交易信息、所述最后一个交易子链的子链数字签名和本地保存的私钥生成与所述交易对应的数字签名；
    根据所述与所述交易对应的数字签名和所述交易信息生成与所述交易对应的交易子链，所述与所述交易对应的交易子链中的子链数字签名为所述与所述交易对应的数字签名；
    生成包括所述与所述交易对应的交易子链的第一验证结果。
  24. 根据权利要求21所述的第一电子设备，其特征在于，所述可信执行环境TEE模块具体用于：
    根据所述冠字号将所述与所述交易对应的交易子链更新到通过所述基本验证的币串凭证上。
  25. 根据权利要求24所述的第一电子设备，其特征在于，所述富执行环境REE模块还用于将所述更新后的通过所述基本验证的币串凭证同步到服务器。
  26. 一种第二电子设备，其特征在于，所述第二电子设备包括富执行环境REE模块、可信执行环境TEE模块和安全单元SE模块：
    所述富执行环境REE模块用于：接收来自第一电子设备的第二交易请求消息，并将所述第二交易请求消息发送给所述可信执行环境TEE模块，所述第二交易请求消息包含至少一个数据凭证；
    所述可信执行环境TEE模块用于：根据所述至少一个数据凭证执行第二业务逻辑以获得第二验证指令，向所述安全单元SE模块发送所述第二验证指令，所述第二验证指令包括待验证的数字签名；
    所述安全单元SE模块用于：根据所述待验证的数字签名验证所述至少一个数据凭证的合法性以获得第二验证结果，并将所述第二验证结果发送给所述可信执行环境TEE模块，所述第二验证结果指示所述至少一个数据凭证的合法性是否验证通过；
    所述可信执行环境TEE模块还用于：接收来自所述安全单元SE模块的所述第二验证结果，保存所述验证通过的数据凭证，发送第二交易响应消息给所述富执行环境REE模块，所述第二交易响应消息用于指示交易是否成功；
    所述富执行环境REE模块还用于：发送第二交易响应消息给第一电子设备。
  27. 根据权利要求26所述的第二电子设备，其特征在于，所述数据凭证包括币串凭证，所述币串凭证包括原始币串或者原始币串以及至少一个交易子链，所述原始币串包括原始币串金额、发行机构证书、发行机构签名，所述交易子链包括与所述交易子链对应的子链数字签名。
  28. 根据权利要求27所述的第二电子设备，其特征在于，所述第二业务逻辑包括原始币串的机构签名验证或所述币串凭证的最后一个交易子链的前序交易的验证。
  29. 根据权利要求26所述的第二电子设备，其特征在于，所述安全单元SE模块具体用于：
    验证所述至少一个币串凭证的每个币串凭证的最后一个交易子链的合法性。
  30. 根据权利要求29所述的第二电子设备，其特征在于，所述安全单元SE模块还用于：
    所述最后一个交易子链的合法性验证通过后，保存所述最后一个交易子链的子链数字签名，所述最后一个交易子链的子链数字签名用于后续交易时作为对比验证的参考值。
  31. 一种服务器，其特征在于，包括接收模块、验证模块和保存模块：
    所述接收模块用于：接收来自电子设备的数据凭证；
    所述验证模块用于：对所述数据凭证进行增量验证，所述增量验证包括将所述数据凭证与保存在所述服务器的历史数据凭证进行对比，验证所述历史数据凭证没有记录的所述数据凭证的数据的合法性；
    所述保存模块用于：保存所述合法性验证成功的所述数据凭证。
  32. 根据权利要求31所述的服务器，其特征在于，所述数据凭证包括币串凭证，所述币串凭证包括原始币串或者原始币串以及至少一个交易子链，其中，所述原始币串包括原始币串金额、发行机构证书和发行机构签名，所述交易子链包括交易金额、交易信息、公钥和子链数字签名，所述子链数字签名为根据前一次交易对应的数字签名与本次交易数据生成的数字签名。
  33. 根据权利要求32所述的服务器，其特征在于，所述币串凭证包括冠字号，所述冠字号为所述币串凭证的唯一标识；
    所述验证模块具体用于：
    根据所述冠字号查询所述服务器是否存在与所述冠字号对应的历史币串凭证，当所述服务器存在与所述币串凭证具有相同冠字号的历史币串凭证时，遍历所述币串凭证的交易子链，验证所述币串凭证中比所述历史币串凭证多出的未验证的交易子链。
  34. 根据权利要求32所述的服务器，其特征在于，所述验证模块具体用于：
    当所述服务器不存在与所述币串凭证具有相同冠字号的历史币串凭证时，对所述币串凭证中的所有交易子链进行验证。
  35. 根据权利要求33或34所述的服务器，其特征在于，所述验证模块具体用于：
    验证子链数字签名、发行机构签名、余额和交易流水。
  36. 根据权利要求33或34所述的服务器，其特征在于，所述保存模块具体用于：
    根据所述冠字号将已验证的所述交易子链的子链数字签名作为特征数据存储到所述服务器。
  37. 一种电子设备，其特征在于，所述电子设备包括存储器和一个或多个处理器，所述一个或多个处理器与所述存储器耦合，其特征在于：
    所述存储器用于存储程序；
    所述一个或多个处理器，用于执行所述存储器中的程序，使得所述电子设备执行如权利要求1-7中任一项所述的方法；或者，使得所述电子设备执行如权利要求8-12中任一项所述的方法。
  38. 一种服务器，其特征在于，所述服务器包括存储器和一个或多个处理器，所述一个或多个处理器与所述存储器耦合，其特征在于：
    所述存储器用于存储程序；
    所述一个或多个处理器，用于执行所述存储器中的程序，使得所述服务器执行如权利要 求13-18中任一项所述的方法。
  39. 一种交易验证的系统，其特征在于，所述系统包括：
    权利要求19至25中任一项所述的装置、权利要求26至30中任一项所述的装置以及权利要求31至36中任一项所述的装置。
  40. 一种计算机可读存储介质，其特征在于，包括计算机程序，所述计算机程序当在一个或多个处理器上运行的时候用于实现所述权利要求1-7中任意一项所述的方法；或者实现所述权利要求8-12中任意一项所述的方法；或者实现所述权利要求13-18中任意一项所述的方法。
PCT/CN2021/080336 2020-07-20 2021-03-12 交易验证的方法、装置 WO2022016886A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP21847389.0A EP4184406A4 (en) 2020-07-20 2021-03-12 TRANSACTION VERIFICATION METHOD AND APPARATUS
US18/156,786 US20230177505A1 (en) 2020-07-20 2023-01-19 Transaction Verification Method and Apparatus

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202010698620.2 2020-07-20
CN202010698620.2A CN113962676A (zh) 2020-07-20 2020-07-20 交易验证的方法、装置

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US18/156,786 Continuation US20230177505A1 (en) 2020-07-20 2023-01-19 Transaction Verification Method and Apparatus

Publications (1)

Publication Number Publication Date
WO2022016886A1 true WO2022016886A1 (zh) 2022-01-27

Family

ID=79459604

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/080336 WO2022016886A1 (zh) 2020-07-20 2021-03-12 交易验证的方法、装置

Country Status (4)

Country Link
US (1) US20230177505A1 (zh)
EP (1) EP4184406A4 (zh)
CN (1) CN113962676A (zh)
WO (1) WO2022016886A1 (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115082067A (zh) * 2022-07-27 2022-09-20 北京大学 一种基于sm2的数字货币双离线支付方法及装置
CN116151827A (zh) * 2023-04-04 2023-05-23 北京银联金卡科技有限公司 一种数字钱包安全框架及基于安全框架的双离线交易方法
WO2024027869A1 (de) * 2022-08-01 2024-02-08 Giesecke+Devrient Advance52 Gmbh Sicheres element, verfahren zum registrieren von token und tokenreferenzregister

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4318355A1 (en) * 2021-03-31 2024-02-07 Digital Currency Institute, The People's Bank of China Methods and apparatuses for generating, verifying and storing transaction voucher, device, and system

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105590201A (zh) * 2015-04-23 2016-05-18 中国银联股份有限公司 移动支付装置及移动支付系统
CN106355252A (zh) * 2016-08-29 2017-01-25 桂林电子科技大学 一种基于访问控制权限的asp知识库增量式验证方法
CN106506472A (zh) * 2016-11-01 2017-03-15 黄付营 一种安全的移动终端电子认证方法及系统
CN108768963A (zh) * 2018-05-11 2018-11-06 北京握奇智能科技有限公司 可信应用与安全元件的通信方法和系统
CN109766152A (zh) * 2018-11-01 2019-05-17 华为终端有限公司 一种交互方法及装置
CN110401538A (zh) * 2018-04-24 2019-11-01 北京握奇智能科技有限公司 数据加密方法、系统以及终端
CN111245620A (zh) * 2018-11-29 2020-06-05 北京中金国信科技有限公司 一种在终端中的移动安全应用架构及其构建方法

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3146747B1 (en) * 2014-05-21 2020-07-01 Visa International Service Association Offline authentication
CN108229956A (zh) * 2017-12-13 2018-06-29 北京握奇智能科技有限公司 网银交易方法、装置、系统以及移动终端
EP3764258B1 (en) * 2018-04-27 2023-07-26 Huawei Technologies Co., Ltd. Constructing common trusted application for a plurality of applications

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105590201A (zh) * 2015-04-23 2016-05-18 中国银联股份有限公司 移动支付装置及移动支付系统
CN106355252A (zh) * 2016-08-29 2017-01-25 桂林电子科技大学 一种基于访问控制权限的asp知识库增量式验证方法
CN106506472A (zh) * 2016-11-01 2017-03-15 黄付营 一种安全的移动终端电子认证方法及系统
CN110401538A (zh) * 2018-04-24 2019-11-01 北京握奇智能科技有限公司 数据加密方法、系统以及终端
CN108768963A (zh) * 2018-05-11 2018-11-06 北京握奇智能科技有限公司 可信应用与安全元件的通信方法和系统
CN109766152A (zh) * 2018-11-01 2019-05-17 华为终端有限公司 一种交互方法及装置
CN111245620A (zh) * 2018-11-29 2020-06-05 北京中金国信科技有限公司 一种在终端中的移动安全应用架构及其构建方法

Non-Patent Citations (1)

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

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115082067A (zh) * 2022-07-27 2022-09-20 北京大学 一种基于sm2的数字货币双离线支付方法及装置
WO2024027869A1 (de) * 2022-08-01 2024-02-08 Giesecke+Devrient Advance52 Gmbh Sicheres element, verfahren zum registrieren von token und tokenreferenzregister
CN116151827A (zh) * 2023-04-04 2023-05-23 北京银联金卡科技有限公司 一种数字钱包安全框架及基于安全框架的双离线交易方法

Also Published As

Publication number Publication date
EP4184406A4 (en) 2023-11-22
EP4184406A1 (en) 2023-05-24
US20230177505A1 (en) 2023-06-08
CN113962676A (zh) 2022-01-21

Similar Documents

Publication Publication Date Title
WO2022016886A1 (zh) 交易验证的方法、装置
US10783260B2 (en) Method for providing simplified account registration service and user authentication service, and authentication server using same
EP3396576B1 (en) Client apparatus, server apparatus and access control system for authorized access
WO2020107233A1 (zh) 基于区块链的钱包系统及钱包使用方法、以及存储介质
US20230090296A1 (en) Transaction verification of a transaction based on a blockchain network
JP2023532959A (ja) 許可制ブロックチェーンのためのプライバシー保護アーキテクチャ
EP3867849B1 (en) Secure digital wallet processing system
KR101976787B1 (ko) 블록체인에서 스마트 컨트랙트를 이용한 전자 문서 유통 방법
CN109347800A (zh) 一种数字货币账户处理方法、装置及系统
KR20190132159A (ko) 스마트 컨트랙트를 이용한 블록체인 기반 암호화폐 거래 플랫폼 제공 방법
CN109067544A (zh) 一种软硬结合的私钥验证方法、装置及系统
CN110930152A (zh) 一种基于区块链的数据处理方法及相关设备
JP7146093B2 (ja) ブロックチェーンでノード間のブロック及び電子文書を共有及び検証する方法
CN111597269A (zh) 一种基于区块链的合约实现方法、装置及设备
US20230421369A1 (en) Systems and Methods Using Distributed Ledgers to Correct for Missing One Time Passwords in Event Processing
KR102376783B1 (ko) 블록체인 기반의 거래내역 확인 시스템
KR20190086301A (ko) 블록 체인을 이용한 분산 데이터베이스 시스템 및 방법
US11978118B2 (en) Event management and validation platform using a recursive hierarchic blockchain
CN114511321B (zh) 基于点对点的数据处理方法、系统、计算设备及存储介质
KR20190132160A (ko) 스마트 컨트랙트를 이용한 암호화폐 거래 플랫폼 제공 방법
CN107493289A (zh) 一种网银安全认证方法及装置
JP2022032116A (ja) データ移行方法、データ移行システム、およびノード
CN111259411A (zh) 区块链管理方法、装置、电子设备及可读存储介质
US20200104228A1 (en) Asynchronous self-proving transactions
CN111915313B (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: 21847389

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2021847389

Country of ref document: EP

Effective date: 20230215