WO2021047281A1 - 一种硬件钱包绑定授权的方法及装置 - Google Patents

一种硬件钱包绑定授权的方法及装置 Download PDF

Info

Publication number
WO2021047281A1
WO2021047281A1 PCT/CN2020/102170 CN2020102170W WO2021047281A1 WO 2021047281 A1 WO2021047281 A1 WO 2021047281A1 CN 2020102170 W CN2020102170 W CN 2020102170W WO 2021047281 A1 WO2021047281 A1 WO 2021047281A1
Authority
WO
WIPO (PCT)
Prior art keywords
hardware wallet
terminal
verification
binding
authorization
Prior art date
Application number
PCT/CN2020/102170
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 US17/606,344 priority Critical patent/US11863684B2/en
Publication of WO2021047281A1 publication Critical patent/WO2021047281A1/zh

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
    • 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
    • G06Q20/3674—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 involving authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3234—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • 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/3827—Use of message hashing
    • 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/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0869—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving random numbers or seeds
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0877—Generation of secret information including derivation or calculation of cryptographic keys or passwords using additional device, e.g. trusted platform module [TPM], smartcard, USB or hardware security module [HSM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN

Definitions

  • the invention relates to a method and device for binding authorization of a hardware wallet, belonging to the field of information security.
  • a hardware wallet is a plug-and-play device that stores the private key of digital assets in a chip, isolated from the Internet, and is plug-and-play.
  • the hardware wallet adopts a pairing code and a PIN code verification method.
  • the terminal is connected to the hardware wallet for the first time, the pairing code and the PIN code of the hardware wallet need to be verified, and the pairing code and PIN code of the hardware wallet must be verified successfully.
  • the hardware wallet is lost, once the PIN code and pairing code are guessed by an illegal user, and the hardware wallet is successfully connected to the terminal, the illegal user can transfer the assets of the legal user, thereby causing the legal user's property to be a security risk.
  • the purpose of the present invention is to provide a method and device for binding authorization of a hardware wallet, which can ensure the security of user assets when the hardware wallet is lost or unauthorized.
  • a method for binding authorization with a hardware wallet which includes:
  • Step S1 When the hardware wallet receives the instruction sent by the terminal, it judges the type of the instruction. If it is an instruction to query the binding status, execute step S2; if it is an instruction to generate an authorization code, execute step S5; if it is a binding instruction, execute step S5. S7;
  • Step S2 The hardware wallet judges the value of the internally stored verification data existence flag, if it is the first preset data, sets the binding object to empty, sets the authorization status to allow the generation of authorization codes, and executes step S4; Step S3 is executed for the second preset data;
  • Step S3 The hardware wallet judges whether the verification data in the binding state query instruction is consistent with the stored verification data, if yes, the binding object is set to the terminal corresponding to the hardware wallet, and step S4 is executed, otherwise it will be bound The object is set to other terminals, and step S4 is executed;
  • Step S4 The hardware wallet organizes command response data according to the binding object and the saved hardware wallet certificate and returns it to the terminal, and returns to step S1;
  • Step S5 The hardware wallet judges whether the authorization status is permission to generate a status code, if yes, execute step S6, otherwise return an error message to the terminal, and return to step S1;
  • Step S6 The hardware wallet generates an authorization code, caches and displays it, sets the authorization status to no longer generate an authorization code, sets the hardware wallet status to unbound, returns a success message to the terminal, and returns to step S1;
  • Step S7 The hardware wallet judges whether the hardware wallet status is unbound, if yes, obtain the cached authorization code, and execute step S8, otherwise obtain the stored authorization code, and execute step S10;
  • Step S8 The hardware wallet uses the obtained authorization code to verify the binding instruction, if the verification succeeds, execute step S9, if the verification fails, return verification failure information to the terminal, and return to step S1;
  • Step S9 The hardware wallet saves the verification data and the cached authorization code in the binding instruction, sets the value of the verification data existence flag to the second predetermined data, and returns the authorization success message to the terminal, and returns to step S1;
  • Step S10 The hardware wallet uses the obtained authorization code to verify the binding instruction, if the verification is successful, execute step S11, if the verification fails, return a verification failure message to the terminal, and return to step S1;
  • Step S11 The hardware wallet judges whether the currently connected terminal is the terminal corresponding to the hardware wallet according to the binding instruction, if yes, it returns the authorization success message to the terminal, and returns to step S1, otherwise saves the binding Specify the verification data in the instruction, set the value of the verification data existence flag as the second predetermined data, and return authorization success information to the terminal, and return to step S1.
  • the step S9 and the step S11 further include: the hardware wallet sets the binding status code of the hardware wallet and the terminal to a predetermined value;
  • the step S1 also includes: when the hardware wallet judges that the type of the instruction sent by the terminal is a signature instruction, the hardware wallet judges whether the status code bound to the hardware wallet and the terminal is a predetermined value, and if yes, according to the signature instruction Perform a signature operation and return to step S1, otherwise an error message is returned to the terminal.
  • the method further includes: the hardware wallet obtains the value of the verification data existence flag from the preset cache.
  • the hardware wallet generating the authorization code includes:
  • the hardware wallet generates a random number with a preset length, generates a retrieval code according to the random number and a preset character encoding table; and sequentially splices the values of the retrieval code to form an authorization code.
  • the method further includes: the hardware wallet judges whether the binding instruction is legal, if yes, execute step S7, otherwise, return an error message to the terminal and return to step S1.
  • the hardware wallet judges whether the binding instruction is legal, specifically: the hardware wallet judges whether the third byte of data in the binding instruction is the first preset value or the second preset value, And it is judged whether the fourth byte data is the third preset value, if the judgment is all yes, the binding instruction is legal, otherwise the binding instruction is illegal.
  • the step S11 includes: the hardware wallet judges whether the third byte data in the binding instruction is the second preset value, and if yes, returns the authorization success message to the terminal, and returns to step S1, Otherwise, save the verification data in the binding instruction, set the value of the verification data existence flag as the second predetermined data, and return authorization success information to the terminal, and return to step S1.
  • the setting the hardware wallet status to unbound is specifically: the hardware wallet sets the authorization code flag to a preset value;
  • the step S7 includes: the hardware wallet judges whether the authorization code flag is a preset value, and if yes, obtains the cached authorization code, and executes step S8; otherwise, obtains the stored authorization code and executes step S10.
  • the verification of the binding instruction by the hardware wallet using the obtained authorization code includes:
  • Step A1 The hardware wallet calculates the ciphertext of the terminal hash value in the binding instruction according to the authorization code to obtain the first decryption result; calculates the device according to the authorization code, verification data, and hardware wallet public key Hash value
  • Step A2 The hardware wallet judges whether the device hash value is equal to the first decryption result, if yes, the verification is successful, otherwise the verification fails.
  • the step A1 includes:
  • Step b1 The hardware wallet performs a hash operation on the authorization code to obtain a first hash result, performs a hash operation on a preset constant to obtain a second hash result, and performs a hash operation on the first hash result and the second hash result. It is hoped that the result will be XOR calculated to get the XOR result;
  • Step b2 The hardware wallet uses the first 16 bytes of the XOR result as the initial vector for encryption and decryption; according to the key agreement algorithm, the stored verification data and the hardware wallet public key are used for key agreement to obtain the device ciphertext and Save, using the first 16 bytes of data in the ciphertext of the device as the first key;
  • Step b3 The hardware wallet uses the first key and the initial vector to decrypt the ciphertext of the terminal hash value in the binding instruction to obtain a first decryption result; according to the authorization code and verification data , The hardware wallet public key is calculated to obtain the device hash value.
  • the calculation to obtain the device hash value according to the authorization code, the verification data, and the hardware wallet public key is specifically: the authorization code, the verification data, and the hardware wallet public key are sequentially spliced to obtain a splicing Value, hash the spliced value to get the device hash value.
  • a device for binding authorization with a hardware wallet including:
  • the first judgment module is used to judge the type of the instruction when the hardware wallet receives the instruction sent by the terminal. If it is an instruction to query the binding status, it triggers the second judgment module, and if it is an instruction to generate an authorization code, it triggers the third judgment module. If it is a binding instruction, the fourth judgment module is triggered;
  • the second judgment module is used for judging and judging the value of the existence flag of the verification data stored inside, if it is the first preset data, the binding object is set to empty, the authorization status is set to allow the generation of an authorization code, and the second A return module; if it is the second preset data, the judgment setting module is triggered;
  • the judgment setting module is used to judge whether the verification data in the binding state query instruction is consistent with the stored verification data, and if yes, the binding object is set to the terminal corresponding to the hardware wallet, and the first return module is triggered; otherwise Set the binding object to another terminal to trigger the first return module;
  • the first return module is configured to organize command response data according to the binding object and the saved hardware wallet certificate and return it to the terminal to trigger the first judgment module;
  • the third judging module is used to judge whether the authorization status is the permission to generate the status code, if yes, trigger the generation setting module, otherwise return error information to the terminal to trigger the first judgment module;
  • the generating and setting module is used to generate an authorization code and cache and display it, set the authorization status to no longer generate an authorization code, set the hardware wallet status to unbound, and return a success message to the terminal to trigger the first judgment Module
  • the fourth judgment module is used to judge whether the hardware wallet status is unbound, and if yes, obtain the cached authorization code and trigger the first verification module; otherwise, obtain the stored authorization code and trigger the second verification module;
  • the first verification module is configured to use the obtained authorization code to verify the binding instruction, if the verification succeeds, trigger the save setting module, if the verification fails, return verification failure information to the terminal to trigger the first judgment module ;
  • the save setting module is used to save the verification data and the cached authorization code in the binding instruction, set the value of the verification data existence flag to the second predetermined data, and return the authorization success message to the terminal to trigger The first judgment module;
  • the second verification module is configured to use the obtained authorization code to verify the binding instruction, if the verification succeeds, the judgment saving module is triggered, and if the verification fails, the verification failure information is returned to the terminal to trigger the first judgment module ;
  • the judgment saving module is configured to judge whether the currently connected terminal is a terminal corresponding to the hardware wallet according to the binding instruction, and if yes, return a successful authorization message to the terminal to trigger the first judgment module, Otherwise, the verification data in the binding instruction is saved, the value of the verification data existence flag is set to the second predetermined data, and authorization success information is returned to the terminal to trigger the first judgment module.
  • the save setting module is also used to set the binding status code of the hardware wallet and the terminal to a predetermined value
  • the device also includes a signature judgment module, which is used to judge whether the status code bound to the hardware wallet and the terminal is a predetermined value when the first judgment module judges that the type of the command sent by the terminal is a signature command, and if it is The signature instruction performs a signature operation and triggers the first judgment module, otherwise an error message is returned to the terminal, and the first judgment module is triggered.
  • a signature judgment module which is used to judge whether the status code bound to the hardware wallet and the terminal is a predetermined value when the first judgment module judges that the type of the command sent by the terminal is a signature command, and if it is The signature instruction performs a signature operation and triggers the first judgment module, otherwise an error message is returned to the terminal, and the first judgment module is triggered.
  • the device further includes: a first obtaining module, configured to obtain the value of the verification data existence flag from the preset cache.
  • the generating and setting module for generating the authorization code includes: the generating and setting module is used for generating a random number of a preset length, generating a retrieval code according to the random number and a preset character encoding table; and ordering the values of the retrieval code Spliced to form an authorization code.
  • the device further includes a fifth judgment module, configured to judge whether the binding instruction is legal when the first judgment module judges that the type of the instruction is a binding instruction, and if yes, trigger the fourth judgment module Otherwise, an error message is returned to the terminal and the first judgment module is triggered.
  • a fifth judgment module configured to judge whether the binding instruction is legal when the first judgment module judges that the type of the instruction is a binding instruction, and if yes, trigger the fourth judgment module Otherwise, an error message is returned to the terminal and the first judgment module is triggered.
  • the fifth judgment module is specifically configured to judge whether the third byte of data in the binding instruction is a first preset value or not when the first judgment module judges that the type of the instruction is a binding instruction.
  • the second preset value and it is judged whether the fourth byte data is the third preset value, if the judgment is all yes, the fourth judgment module is triggered, otherwise an error message is returned to the terminal, and the first judgment is triggered Module.
  • the judging and saving module is specifically configured to judge whether the third byte of data in the binding instruction is the second preset value, and if yes, it will return the authorization success message to the terminal, otherwise it will save the binding.
  • the value of the verification data existence flag is set to the second predetermined data, and authorization success information is returned to the terminal to trigger the first judgment module.
  • the generating and setting module is used to set the hardware wallet status to unbound, and the specific duration is: the generating and setting module is used to set the authorization code flag to a preset value;
  • the fourth judgment module is specifically configured to judge whether the authorization code flag is a preset value, and if yes, obtain the cached authorization code and trigger the first verification module; otherwise, obtain the saved authorization code and trigger the second verification module.
  • the first verification module includes:
  • the calculation unit is configured to calculate the ciphertext of the terminal hash value in the binding instruction according to the authorization code to obtain the first decryption result; calculate the device hash value according to the authorization code, verification data, and hardware wallet public key;
  • the first judging unit is used to judge whether the device hash value is equal to the first decryption result. If yes, the verification is successful and trigger the save setting module; otherwise, the verification fails and the verification failure information is returned to the terminal to trigger the first Judgment module;
  • the second verification module includes:
  • the calculation unit is configured to calculate the ciphertext of the terminal hash value in the binding instruction according to the authorization code to obtain the first decryption result; calculate according to the authorization code, verification data, and hardware wallet public key to obtain the device hash value ;
  • the second judgment unit is used to judge whether the device hash value is equal to the first decryption result. If yes, the verification is successful and trigger the judgment saving module; otherwise, the verification fails and the verification failure information is returned to the terminal to trigger the first Judgment module.
  • the calculation unit includes:
  • the first calculation subunit is used to perform a hash operation on the authorization code to obtain a first hash result, perform a hash operation on a preset constant to obtain a second hash result, and perform a hash operation on the first hash result and the second hash result.
  • the hash result is XOR calculated, and the XOR result is obtained;
  • the decryption negotiation subunit is used to use the first 16 bytes of the XOR result as the initial vector for encryption and decryption operations; use the stored verification data and the hardware wallet public key to perform key negotiation according to the key agreement algorithm to obtain the device ciphertext and Save, using the first 16 bytes of data in the ciphertext of the device as the first key;
  • the decryption calculation subunit is configured to use the first key and the initial vector to decrypt the ciphertext of the terminal hash value in the binding instruction to obtain a first decryption result; according to the authorization code and verification data , The hardware wallet public key is calculated to obtain the device hash value.
  • the decryption calculation sub-unit is used to calculate the device hash value according to the authorization code, verification data, and hardware wallet public key, specifically: the decryption calculation sub-unit is used to combine the authorization code and the verification
  • the data and the hardware wallet public key are sequentially spliced to obtain a spliced value, and the spliced value is hashed to obtain a device hash value.
  • the terminal and the hardware wallet are bound in a one-to-one correspondence. If the hardware wallet needs to be connected to a new terminal, the authorization code must first determine whether the user authorizes the terminal to connect with the hardware wallet. If authorized, the new terminal is allowed to connect with the hardware wallet. The hardware wallet is connected to ensure the security of the user's assets when the hardware wallet is lost or unauthorized.
  • Fig. 1 is a flowchart of a method for binding authorization with a hardware wallet according to an embodiment of the present invention
  • FIGS. 2 and 3 are flowcharts of a method for binding authorization with a hardware wallet according to the second embodiment of the present invention
  • Fig. 4 is a block diagram of a hardware wallet binding authorization device according to the third embodiment of the present invention.
  • the first embodiment of the present invention provides a method for binding authorization with a hardware wallet, as shown in FIG. 1, including:
  • Step S1 When the hardware wallet receives the instruction sent by the terminal, it judges the type of the instruction. If it is an instruction to query the binding status, execute step S2; if it is an instruction to generate an authorization code, execute step S5; if it is a binding instruction, execute step S5. S7;
  • Step S2 The hardware wallet judges the value of the internally stored verification data existence flag, if it is the first preset data, the binding object is set to empty, the authorization status is set to allow the generation of authorization codes, and step S4 is executed; if it is the first preset data Step S3 is executed for the second preset data;
  • step S2 it further includes: the hardware wallet obtains the value of the verification data existence flag from the preset cache;
  • Step S3 The hardware wallet judges whether the verification data in the binding state query command is consistent with the stored verification data, if yes, set the binding object to the terminal corresponding to the hardware wallet, and perform step S4, otherwise set the binding object to other Terminal, perform step S4;
  • the verification data in the first embodiment may be a terminal public key or other data
  • Step S4 The hardware wallet organizes the command response data according to the binding object and the saved hardware wallet certificate and returns it to the terminal, returning to step S1;
  • Step S5 The hardware wallet judges whether the authorization status is permission to generate a status code, if yes, execute step S6, otherwise return an error message to the terminal, and return to step S1;
  • Step S6 The hardware wallet generates an authorization code, caches and displays it, sets the authorization status to no longer generate authorization codes, sets the hardware wallet status to unbound, returns a success message to the terminal, and returns to step S1;
  • the hardware wallet generating the authorization code includes: the hardware wallet generates a random number of a preset length, and generates the retrieval code according to the random number and the preset character encoding table; and sequentially splicing the values of the retrieval code to form the authorization code ;
  • the hardware wallet status is set to unbound, specifically: the hardware wallet sets the authorization code flag to a preset value;
  • Step S7 The hardware wallet judges whether the hardware wallet status is unbound, if yes, obtain the cached authorization code, and execute step S8, otherwise obtain the stored authorization code, and execute step S10;
  • step S7 includes: the hardware wallet judges whether the authorization code flag is a preset value, if yes, obtains the cached authorization code, and executes step S8; otherwise, obtains the saved authorization code and executes step S10;
  • step S7 it further includes: the hardware wallet judges whether the binding instruction is legal, if yes, execute step S7, otherwise return an error message to the terminal, and return to step S1;
  • the hardware wallet judges whether the binding instruction is legal, specifically: the hardware wallet judges whether the third byte data in the binding instruction is the first preset value or the second preset value, and judges whether the fourth byte data is The third preset value, if the judgment is all yes, the binding instruction is legal, otherwise the binding instruction is illegal;
  • Step S8 The hardware wallet uses the obtained authorization code to verify the binding instruction, if the verification is successful, execute step S9, if the verification fails, return a verification failure message to the terminal, and return to step S1;
  • the hardware wallet uses the obtained authorization code to verify the binding instruction, including:
  • Step A1 The hardware wallet calculates the ciphertext of the terminal hash value in the binding instruction according to the authorization code to obtain the first decryption result; calculates the device hash value according to the authorization code, verification data, and hardware wallet public key;
  • Step A1 in the first embodiment includes:
  • Step b1 The hardware wallet performs a hash operation on the authorization code to obtain a first hash result, performs a hash operation on a preset constant to obtain a second hash result, and performs an exclusive OR calculation on the first hash result and the second hash result Get the XOR result;
  • Step b2 The hardware wallet uses the first 16 bytes of the XOR result as the initial vector for encryption and decryption operations; according to the key agreement algorithm, the saved verification data and the hardware wallet public key are used for key negotiation to obtain the device ciphertext and save it, and the device The first 16 bytes of ciphertext data are used as the first key;
  • the hardware wallet uses the first 16 bytes of the XOR result as the initial vector for the AES encryption and decryption operation;
  • Step b3 The hardware wallet uses the first key and the initial vector to decrypt the ciphertext of the terminal hash value in the binding instruction to obtain the first decryption result; calculate the device according to the authorization code, verification data, and hardware wallet public key. Hope value
  • the device hash value is calculated according to the authorization code, the verification data, and the hardware wallet public key, specifically: the authorization code, the verification data, and the hardware wallet public key are sequentially spliced to obtain the splicing value, and the splicing value is performed Hash operation to get the device hash value;
  • Step A2 The hardware wallet judges whether the device hash value is equal to the first decryption result, if yes, the verification is successful, otherwise the verification fails;
  • Step S9 The hardware wallet saves the verification data and the cached authorization code in the binding instruction, sets the value of the verification data existence flag to the second predetermined data, and returns the authorization success message to the terminal, and returns to step S1;
  • Step S10 The hardware wallet uses the obtained authorization code to verify the binding instruction, if the verification is successful, execute step S11, if the verification fails, return a verification failure message to the terminal, and return to step S1;
  • step S10 is consistent with step S8, and will not be repeated here;
  • Step S11 The hardware wallet judges whether the currently connected terminal is the terminal corresponding to the hardware wallet according to the binding instruction. If yes, it returns the authorization success message to the terminal, and returns to step S1, otherwise the verification data in the binding instruction is saved, and the data will be verified The value of the presence flag is set to the second predetermined data, and authorization success information is returned to the terminal, and step S1 is returned;
  • step S11 includes: the hardware wallet judges whether the third byte data in the binding instruction is the second preset value, and if yes, it returns the authorization success message to the terminal, and returns to step S1, otherwise the binding is saved
  • the hardware wallet judges whether the third byte data in the binding instruction is the second preset value, and if yes, it returns the authorization success message to the terminal, and returns to step S1, otherwise the binding is saved
  • the value of the verification data existence flag is set to the second predetermined data, and authorization success information is returned to the terminal, and step S1 is returned.
  • step S9 and step S11 also include: the hardware wallet sets the binding status code of the hardware wallet to the terminal
  • step S1 also includes: when the hardware wallet determines that the type of instruction sent by the terminal is a signature instruction, the hardware wallet determines whether the state code bound to the hardware wallet and the terminal is a predetermined value, and if it is, it is based on the signature Instruct the signature operation, return to step S1, otherwise return an error message to the terminal.
  • a method for binding authorization with a hardware wallet is provided. As shown in Fig. 2 and Fig. 3, the method includes:
  • Step 101 When the hardware wallet receives the instruction sent by the terminal, it judges the type of the instruction. For example, execute step 102 for query binding status instruction, execute step 112 for generate authorization code instruction, execute step 112 if it is binding instruction 118, if it is a signature instruction, execute step 143;
  • the hardware wallet judges the second byte of data in the received instruction. If it is 0x71, the type of the instruction is the query binding status instruction; if the type of the 0x72 instruction is the generation authorization code Instruction; if it is 0x73, the type of instruction is binding instruction;
  • the hardware wallet after receiving the instruction, the hardware wallet first saves the instruction in the APDU buffer, and then processes it;
  • Step 102 The hardware wallet obtains verification data from the binding status query command:
  • step 102 includes: the hardware wallet stores the received query binding status command in the APDU buffer, and acquires 65 bytes of data from the 5th byte of the APDU buffer as the verification data , And stored in the first buffer area;
  • the verification data in the second embodiment may be the terminal public key;
  • Step 103 The hardware wallet obtains the verification data existence flag from the preset buffer area
  • step 103 before step 103, it further includes: the hardware wallet judges whether there is data in the preset cache, if yes, execute step 103, otherwise an error is reported;
  • Step 104 The hardware wallet obtains the hardware wallet certificate from the preset buffer area and stores it in the second buffer area;
  • the hardware wallet certificate includes the hardware wallet public key
  • Step 105 The hardware wallet judges the value of the verification data existence flag, if it is the first predetermined data, execute step 106, and if it is the second predetermined data, execute step 108;
  • the first predetermined data is 0x0000; the second predetermined data is 0x5AA5;
  • Step 106 The hardware wallet setting binding object is set to empty
  • the hardware wallet sets the value of the binding object to 0x00;
  • Step 107 The hardware wallet sets the authorization status to allow the generation of authorization codes, and executes step 111;
  • the hardware wallet sets the authorization status to 0xA5;
  • Step 108 The hardware wallet judges whether the verification data in the binding state query command is equal to the stored verification data, if yes, proceed to step 109, otherwise proceed to step 110;
  • Step 109 The hardware wallet setting binding object is set to the terminal corresponding to the hardware wallet, and step 111 is performed;
  • the hardware wallet sets the value of the binding object to 0x55;
  • Step 110 The hardware wallet sets the binding object to another terminal, and executes step 111;
  • the hardware wallet sets the value of the binding object to 0xAA
  • Step 111 The hardware wallet organizes the command response data according to the binding object and the hardware wallet certificate and returns it to the terminal, returning to step 101;
  • the terminal obtains the value of the binding object from the received response data. If it is 0x00, the hardware wallet is not bound to the new device, and the terminal sends a binding instruction to the hardware wallet device; if it is 0x55, the hardware wallet The bound device is the current terminal. If it is 0xAA, the hardware wallet is bound to other terminals, and the terminal sends an instruction to generate an authorization code to the hardware wallet;
  • the terminal receives the response data and parses the response data to know that the binding object is empty, it will generate an authorization code command under the hardware wallet. For example, if the response data is parsed, the binding object is found to correspond to the hardware wallet. The terminal or other terminals will issue binding instructions to the hardware wallet;
  • Step 112 The hardware wallet judges whether the authorization status is that the authorization code is allowed to be generated, if yes, proceed to step 113, otherwise an error message is returned to the terminal;
  • the hardware wallet judges whether the authorization status is 0xA5, and if yes, proceed to step 113, otherwise an error message is returned to the terminal; preferably, the error message is 9000;
  • Step 113 The hardware wallet generates an 8-byte random number, and generates a retrieval code according to the random number and the preset character encoding table;
  • the hardware wallet generates the retrieval code according to the random number and the preset character encoding table, including: the hardware wallet obtains the character encoding value corresponding to the nth byte of the random number in the preset character encoding table modulo 32
  • the index is used as the search code for SEED;
  • the default character code table is the following character code RANDOM_SEED (0-9, AZ has been removed from '0', '1','I', and'O'), a total of 32;
  • Step 114 the hardware wallet splices the value of the retrieval code sequentially to form the authorization code and caches it;
  • the cached authorization code will be cleared
  • Step 115 The hardware wallet displays the authorization code
  • the user records the authorization code displayed by the hardware wallet on paper and saves it securely.
  • the hardware wallet is bound to the current device or other equipment, the user enters the recorded authorization code into the terminal, and the terminal is authorized according to the authorization code.
  • Code calculation terminal data and send it to the hardware wallet, the hardware wallet verifies the received terminal data through the cached or saved authorization code;
  • Step 116 The hardware wallet sets the authorization status to no longer generate authorization codes
  • the hardware wallet sets the authorization status to 0x5A;
  • Step 117 The hardware wallet sets the authorization code flag to be the first time the hardware wallet binds the device, and returns a success message to the terminal, and returns to step 101:
  • the hardware wallet sets the authorization code flag to 0xA5;
  • Step 118 The hardware wallet judges whether it is a binding device operation or a verification device operation according to the third byte of the binding instruction, if yes, execute step 119, otherwise set the status code, and return an error message to the terminal according to the set status code;
  • step 118 further includes: the hardware wallet judges whether the fourth byte data of the binding instruction is 0;
  • the hardware wallet judges the value of the third byte of the binding instruction. If it is 0x00 or 0x80, the terminal is binding device operation or verifying device operation; the set status code is 6a86, indicating that the values of P1 and P2 are wrong;
  • Step 119 The hardware wallet judges whether the hardware wallet is used to bind the device for the first time according to the authorization code mark. If yes, obtain the cached authorization code, and execute step 120; otherwise, obtain the saved authorization code and execute step 131;
  • the hardware wallet determines whether the authorization code flag is 0xA5. If yes, the cached authorization code can be used directly, and the execution step is 120. Otherwise, the saved authorization code is obtained and step 120 is executed; in this embodiment In the second, if a power failure occurs after the authorization code is saved, the saved authorization code can continue to be used after the hardware wallet is turned on next time;
  • Step 120 the hardware wallet performs a hash operation on the authorization code to obtain a first hash result, and performs a hash operation on a preset constant to obtain a second hash result;
  • the preset constant in the second embodiment is 0x62 0x69 0x6e 0x64 0x69 0x6e 0x67 0x43 0x6f 0x64 0x65;
  • Step 121 The hardware wallet performs an exclusive OR calculation on the first hash result and the second hash result to obtain the exclusive OR result;
  • Step 122 The hardware wallet uses the first 16 bytes of the XOR result as the initial vector for the AES encryption and decryption operation;
  • Step 123 The hardware wallet obtains the verification data, uses the verification data and the hardware wallet public key to perform key negotiation according to the key agreement algorithm to obtain the device ciphertext and save it, using the first 16 bytes of the device ciphertext as the first key;
  • the hardware wallet uses the data at bytes 6 to 70 in the APDU buffer as verification data; the key agreement algorithm is specifically ECDH;
  • step 122 and step 123 can be changed;
  • Step 124 The hardware wallet uses the first key and the initial vector to decrypt the ciphertext of the terminal hash value in the APDU buffer to obtain the first decryption result;
  • the ciphertext of the terminal hash value is located 32 bytes after the 70th byte of the APDU buffer;
  • Step 125 The hardware wallet calculates the device hash value according to the authorization code, verification data, and hardware wallet public key;
  • calculating the device hash value is specifically: concatenating the authorization code, the verification data, and the hardware wallet public key in order to obtain the splicing value, and performing a hash operation on the splicing value to obtain the device hash value;
  • step 124 and step 125 in the second embodiment can be changed;
  • Step 126 The hardware wallet judges whether the device hash value is equal to the first decryption result, if yes, go to step 127, otherwise go to step 130;
  • Step 127 The hardware wallet sets the first byte in the APDU buffer area as the verification success information:
  • the hardware wallet sets the first byte in the APDU buffer area to 0x5A;
  • Step 128 The hardware wallet saves the authorization code and the verification data in the binding instruction, sets the value of the verification data existence flag as the second predetermined data, and executes step 129;
  • the value of the verification data existence flag is set to 0x5AA5;
  • Step 129 The hardware wallet prompts on the screen that the authorization is successful, and returns the verification pass information and status code in the APDU buffer area to the terminal, and returns to step 101;
  • the hardware wallet prompts the authorization success on the screen as: the hardware wallet displays the authorization success prompt message on the screen;
  • the status code in the second embodiment is 9000;
  • Step 130 The hardware wallet sets the first byte in the APDU buffer area as a verification failure, prompts the authorization failure on the screen and returns a verification failure message to the terminal, and returns to step 101;
  • the first byte of the hardware wallet APDU buffer area is set to be verified, specifically: the first byte of data in the hardware wallet APDU buffer area is set to 0xA5;
  • the hardware wallet prompts the authorization failure on the screen as follows: the hardware wallet displays the authorization failure prompt message on the screen;
  • Step 131 The hardware wallet performs a hash operation on the authorization code to obtain a first hash result, and performs a hash operation on a preset constant to obtain a second hash result;
  • the preset constant in the second embodiment is 0x62 0x69 0x6e 0x64 0x69 0x6e 0x67 0x43 0x6f 0x64 0x65;
  • Step 132 The hardware wallet performs an exclusive OR calculation on the first hash result and the second hash result to obtain the exclusive OR result;
  • Step 133 The hardware wallet uses the first 16 bytes of the XOR result as the initial vector for the AES encryption and decryption operation;
  • Step 134 the hardware wallet obtains the verification data, uses the verification data and the hardware wallet public key to perform key negotiation according to the key agreement algorithm, obtains and saves the device ciphertext, and uses the first 16 bytes of the device ciphertext as the first key;
  • the hardware wallet uses the data at bytes 6 to 70 in the APDU buffer as verification data; the key agreement algorithm is specifically ECDH;
  • step 133 and step 134 can be changed;
  • Step 135 The hardware wallet uses the first key and the initial vector to decrypt the ciphertext of the terminal hash value in the APDU buffer to obtain the first decryption result;
  • the ciphertext of the terminal hash value is located 32 bytes after the 70th byte of the APDU buffer;
  • Step 136 The hardware wallet calculates the device hash value according to the authorization code, verification data, and hardware wallet public key;
  • calculating the device hash value is specifically: concatenating the authorization code, the verification data, and the hardware wallet public key in order to obtain the splicing value, and performing a hash operation on the splicing value to obtain the device hash value;
  • step 136 and step 137 in the second embodiment can be changed;
  • Step 137 The hardware wallet judges whether the device hash value is equal to the first decryption result, if yes, go to step 138, otherwise go to step 142;
  • Step 138 The hardware wallet sets the first byte in the APDU buffer area as the verification success information:
  • the hardware wallet sets the first byte in the APDU buffer area to 0x5A;
  • Step 139 The hardware wallet judges whether the currently connected terminal is the terminal corresponding to the hardware wallet according to the third byte data in the binding instruction, if yes, go to step 141, otherwise go to step 140;
  • the hardware wallet judges whether the third byte of data in the binding instruction is 0x80, if yes, the terminal operates as a bound device, otherwise the terminal does not operate as a bound device;
  • Step 140 the hardware wallet saves the verification data in the binding instruction, sets the value of the verification data existence flag as the second predetermined data, and executes step 141;
  • the value of the verification data existence flag is set to 0x5AA5;
  • Step 141 The hardware wallet prompts that the authorization is successful on the screen, and returns the verification pass information and status code in the APDU buffer area to the terminal, and returns to step 101;
  • the hardware wallet prompts the authorization success on the screen as: the hardware wallet displays the authorization success prompt message on the screen;
  • the status code in the second embodiment is 9000;
  • Step 142 The hardware wallet sets the first byte in the APDU buffer area as verification failure, prompts the authorization failure on the screen and returns verification failure information to the terminal, and returns to step 101;
  • the first byte of the hardware wallet APDU buffer area is set to be verified, specifically: the first byte of data in the hardware wallet APDU buffer area is set to 0xA5;
  • the hardware wallet prompts the authorization failure on the screen as follows: the hardware wallet displays the authorization failure prompt message on the screen;
  • Step 143 The hardware wallet judges whether the status code bound between the hardware wallet and the terminal is a predetermined value, and if yes, it uses the hardware wallet private key to sign the data to be signed in the signature instruction and returns the signature result to the terminal, returning to step 101; otherwise Return an error message to the terminal, and return to preparation 101.
  • the technical scheme of the present invention binds the terminal and the hardware wallet in a one-to-one correspondence. If the hardware wallet needs to be connected to the terminal, the authorization code must be used to determine whether the user authorizes the terminal to connect with the hardware wallet. If authorized, the terminal is allowed to connect with the hardware wallet. , To ensure the safety of user assets when the hardware wallet is lost.
  • a device for binding authorization with a hardware wallet is provided, as shown in FIG. 4, which includes:
  • the first judgment module 30 is used for judging the type of the instruction when the hardware wallet receives the instruction sent by the terminal. If it is an instruction to query the binding status, the second judging module 31 is triggered, and if it is an instruction to generate an authorization code, the third judgment is triggered. Module 34, if it is a binding instruction, trigger the fourth judgment module 36;
  • the second judgment module 31 is used for judging and judging the value of the existence flag of the internally stored verification data, if it is the first preset data, the binding object is set to empty, the authorization status is set to allow the generation of authorization codes, and the first Return to module 33; otherwise, trigger the judgment setting module 32;
  • the judgment setting module 32 is used to judge whether the verification data in the binding state query instruction is consistent with the stored verification data. If yes, the binding object is set to the terminal corresponding to the hardware wallet, and the first return module 33 is triggered, otherwise the binding The predetermined object is set to another terminal, and the first return module 33 is triggered;
  • the first return module 33 is configured to organize the command response data according to the binding object and the saved hardware wallet certificate and return it to the terminal to trigger the first judgment module 30;
  • the third judgment module 34 is used for judging whether the authorization status is the permission to generate the status code, and if yes, the generation setting module 35 is triggered, otherwise an error message is returned to the terminal, and the first judgment module 30 is triggered;
  • the generation setting module 35 is used to generate the authorization code and cache and display it, set the authorization status to no longer generate authorization code, set the hardware wallet status to unbound, and return a success message to the terminal to trigger the first judgment module 30;
  • generating a setting module 35 for generating an authorization code includes: generating a setting module 35 for generating a random number with a preset length, and generating a retrieval code according to the random number and a preset character encoding table; The value of the retrieval code is concatenated to form an authorization code;
  • the fourth judgment module 36 is used to judge whether the hardware wallet status is unbound, and if yes, obtain the cached authorization code and trigger the first verification module 37; otherwise, obtain the stored authorization code and trigger the second verification module 39;
  • the first verification module 37 is configured to use the obtained authorization code to verify the binding instruction. If the verification succeeds, the save setting module 38 is triggered, and if the verification fails, the verification failure information is returned to the terminal to trigger the first judgment module 30;
  • the save setting module 38 is used to save the verification data and the cached authorization code in the binding instruction, set the value of the verification data existence flag to the second predetermined data, and return the authorization success message to the terminal to trigger the first judgment module 30 ;
  • the second verification module 39 is configured to use the obtained authorization code to verify the binding instruction. If the verification is successful, the storage module 40 is judged, and if the verification fails, the verification failure information is returned to the terminal to trigger the first judgment module 30;
  • the judging and saving module 40 is used to judge whether the currently connected terminal is the terminal corresponding to the hardware wallet according to the binding instruction, and if yes, it will return the authorization successful information to the terminal and trigger the first judging module 30, otherwise save the verification in the binding instruction Data, the value of the verification data existence flag is set to the second predetermined data, and authorization success information is returned to the terminal, and the first judgment module 30 is triggered.
  • the save setting module 38 is also used to set the binding status code of the hardware wallet and the terminal to a predetermined value
  • the device further includes a signature judgment module for judging whether the status code of the hardware wallet and the terminal is a predetermined value when the first judgment module 30 judges that the type of the command sent by the terminal is a signature command.
  • the signature instruction performs a signature operation and triggers the first judgment module; otherwise, an error message is returned to the terminal and the first judgment module is triggered.
  • the device in the third embodiment further includes: a first obtaining module, configured to obtain the value of the verification data existence flag from the preset cache.
  • the device in the third embodiment also includes a fifth judging module, which is used to judge whether the binding instruction is legal when the first judging module 30 judges that the type of the instruction is a binding instruction. If it is, the fourth judging module 36 is triggered; otherwise, The terminal returns error information, triggering the first judgment module 30.
  • the fifth judging module is specifically configured to judge whether the third byte of data in the binding instruction is the first preset value or the first when the first judging module 30 judges that the type of the instruction is a binding instruction. Two preset values, and it is judged whether the fourth byte data is the third preset value, if the judgment is all yes, the fourth judgment module 36 is triggered; otherwise, an error message is returned to the terminal and the first judgment module 30 is triggered.
  • the judging and saving module 40 is specifically used to judge whether the third byte of data in the binding instruction is the second preset value, and if yes, it will return the authorization success message to the terminal, otherwise it will save the data in the binding instruction. Verify the data, set the value of the verification data existence flag to the second predetermined data, and return authorization success information to the terminal, triggering the first judgment module.
  • the generating and setting module 35 is used to set the hardware wallet status to unbound, specifically: the generating and setting module 35 is used to set the authorization code flag to a preset value; the fourth determining module 36 is specifically used to determine the authorization code If the flag is a preset value, if yes, the cached authorization code is obtained and the first verification module 37 is triggered; otherwise, the saved authorization code is obtained and the second verification module 39 is triggered.
  • the first verification module 37 includes:
  • the calculation unit is configured to calculate the ciphertext of the terminal hash value in the binding instruction according to the authorization code to obtain the first decryption result; calculate the device hash value according to the authorization code, verification data, and hardware wallet public key;
  • the calculation unit includes:
  • the first calculation subunit is used to perform a hash operation on the authorization code to obtain a first hash result, perform a hash operation on a preset constant to obtain a second hash result, and perform a hash operation on the first hash result and the second hash result XOR calculation, get XOR result;
  • the decryption negotiation subunit is used to use the first 16 bytes of the XOR result as the initial vector for encryption and decryption operations; use the saved verification data and the hardware wallet public key for key negotiation according to the key agreement algorithm to obtain the device ciphertext and save it , Use the first 16 bytes of the device ciphertext as the first key;
  • the decryption negotiation subunit is used to use the first 16 bytes of the XOR result as the initial vector for the AES encryption and decryption operation;
  • the decryption calculation subunit is used to decrypt the ciphertext of the terminal hash value in the binding instruction using the first key and the initial vector to obtain the first decryption result; calculate according to the authorization code, verification data, and hardware wallet public key, Get the device hash value;
  • the decryption calculation subunit is used to calculate the device hash value according to the authorization code, verification data, and hardware wallet public key. Specifically: the decryption calculation subunit is used to transfer the authorization code, verification data, and hardware wallet The public keys are sequentially spliced to obtain the spliced value, and the spliced value is hashed to obtain the device hash value;
  • the first judgment unit is used to judge whether the device hash value is equal to the first decryption result. If yes, the verification is successful and trigger the save setting module 38; otherwise, the verification fails, and the verification failure information is returned to the terminal to trigger the first judgment module 30;
  • the second verification module 39 includes:
  • the calculation unit is configured to calculate the ciphertext of the terminal hash value in the binding instruction according to the authorization code to obtain the first decryption result; calculate according to the authorization code, the verification data, and the hardware wallet public key to obtain the device hash value;
  • the second judgment unit is used to judge whether the device hash value is equal to the first decryption result. If yes, the verification is successful and trigger the judgment saving module; otherwise, the verification fails, and the verification failure information is returned to the terminal to trigger the first judgment module.

Landscapes

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

Abstract

一种硬件钱包绑定授权的方法，该方法包括：当硬件钱包接收到查询绑定状态指令，则判断验证数据存在性标志的值，如为第一预设数据，则将绑定对象设置为空，将授权状态设为允许生成授权码；如为第二预设数据，则将绑定对象设置为与硬件钱包对应的终端或其他终端；将绑定对象和保存的硬件钱包证书返回给终端；当硬件钱包接收到生成授权码指令时，如授权状态为允许生成状态码，则生成授权码并缓存和显示，将授权状态设为不能再生成授权码，将硬件钱包状态设为未绑定；当硬件钱包接收到绑定指令，则使用获取的授权码对绑定指令进行验证，如验证成功则绑定成功。终端只有通过用户授权才能与硬件钱包进行连接，从而保证了用户资产的安全。

Description

一种硬件钱包绑定授权的方法及装置 技术领域
本发明涉及一种硬件钱包绑定授权的方法及装置，属于信息安全领域。
背景技术
硬件钱包是一种将数字资产私钥单独储存在一个芯片中，与互联网隔离，即插即用的设备。在现有技术中，硬件钱包采用配对码和PIN码验证方式，终端与硬件钱包首次连接时需对硬件钱包的配对码和PIN码进行验证，两者均验证成功后才可以连接使用。当硬件钱包丢失后，一旦被非法用户猜中PIN码和配对码，将硬件钱包成功连接到终端，该非法用户便可以转移合法用户的资产，从而导致合法用户的财产存在安全隐患。
发明内容
本发明的目的是提供一种硬件钱包绑定授权的方法及装置，其可保证在硬件钱包丢失时或未授权时用户资产的安全性。
为此，根据本发明的一个方面，提供了一种硬件钱包绑定授权的方法，包括：
步骤S1：当硬件钱包接收到终端发送的指令时，判断指令的类型，如为查询绑定状态指令则执行步骤S2，如为生成授权码指令则执行步骤S5，如为绑定指令则执行步骤S7；
步骤S2：所述硬件钱包判断内部保存的验证数据存在性标志的值，如为第一预设数据则将绑定对象设置为空，将授权状态设为允许生成授权码，执行步骤S4；如为第二预设数据则执行步骤S3；
步骤S3：所述硬件钱包判断查询绑定状态指令中的验证数据和保存的验证数据是否一致，是则将绑定对象设置为与所述硬件钱包对应的终端，执行步骤S4，否则将绑定对象设置为其他终端，执行步骤S4；
步骤S4：所述硬件钱包根据绑定对象和保存的硬件钱包证书组织命令响应数据并返回给所述终端，返回步骤S1；
步骤S5：所述硬件钱包判断授权状态是否为允许生成状态码，是则执行步骤S6，否则给所述终端返回错误信息，返回步骤S1；
步骤S6：所述硬件钱包生成授权码并缓存和显示，将授权状态设为不能再生成授权码，将硬件钱包状态设为未绑定，并给终端返回成功信息，返回步骤S1；
步骤S7：所述硬件钱包判断硬件钱包状态是否为未绑定，是则获取缓存的授权码，执行步骤S8，否则获取保存的授权码，执行步骤S10；
步骤S8：所述硬件钱包使用获取的授权码对所述绑定指令进行验证，如验证成功则执行步骤S9，如验证失败则给终端返回验证失败信息，返回步骤S1；
步骤S9：所述硬件钱包保存所述绑定指令中的验证数据和缓存的授权码，将验证数据存在性标志的值设为第二预定数据，并给所述终端返回授权成功信息，返回步骤S1；
步骤S10：所述硬件钱包使用获取的授权码对所述绑定指令进行验证，如验证成功则执行步骤S11，如验证失败则给终端返回验证失败信息，返回步骤S1；以及
步骤S11：所述硬件钱包根据所述绑定指令判断当前连接的终端是否为与所述硬件钱包对应的终端，是则给所述终端返回授权成功过信息，返回步骤S1，否则保存所述绑定指令中的验证数据，将验证数据存在性标志的值设为第二预定数据，并给所述终端返回授权成功信息，返回步骤S1。
优选地，所述步骤S9和所述步骤S11还包括：所述硬件钱包将硬件钱包与终端的绑定状态码设为预定值；
所述步骤S1还包括：当硬件钱包判断接收到终端发送的指令的类型为签名指令时，所述硬件钱包判断硬件钱包与终端绑定的状态码是否为预定值，是则根据所述签名指令进行签名 操作，返回步骤S1，否则给所述终端返回错误信息。
优选地，所述步骤S2之前还包括：所述硬件钱包从预置缓存中获取验证数据存在性标志的值。
优选地，所述硬件钱包生成授权码包括：
所述硬件钱包生成预设长度的随机数，根据所述随机数和预设字符编码表生成检索码；将检索码的值顺序拼接组成授权码。
优选地，所述步骤S7之前还包括：所述硬件钱包判断所述绑定指令是否合法，是则执行步骤S7，否则给所述终端返回错误信息，返回步骤S1。
优选地，所述硬件钱包判断所述绑定指令是否合法，具体为：所述硬件钱包判断所述绑定指令中的第三字节数据是否为第一预设值或第二预设值、且判断第四字节数据是否为第三预设值，如判断均为是则所述绑定指令合法，否则所述绑定指令不合法。
优选地，所述步骤S11包括：所述硬件钱包判断所述绑定指令中的第三字节数据是否为第二预设值，是则给所述终端返回授权成功过信息，返回步骤S1，否则保存所述绑定指令中的验证数据，将验证数据存在性标志的值设为第二预定数据，并给所述终端返回授权成功信息，返回步骤S1。
优选地，所述将硬件钱包状态设为未绑定，具体为：所述硬件钱包将授权码标记设为预设值；
所述步骤S7包括：所述硬件钱包判断授权码标记是否为预设值，是则获取缓存的授权码，执行步骤S8，否则获取保存的授权码，执行步骤S10。
优选地，所述硬件钱包使用获取的授权码对所述绑定指令进行验证，包括：
步骤A1：所述硬件钱包根据授权码对所述绑定指令中的终端哈希值的密文进行计算得到第一解密结果；根据所述授权码、验证数据、硬件钱包公钥进行计算得到设备哈希值；
步骤A2：所述硬件钱包判断所述设备哈希值与所述第一解密结果是否相等，是则验证成功，否则验证失败。
优选地，所述步骤A1包括：
步骤b1：所述硬件钱包对授权码进行哈希运算得到第一哈希结果，对预置常数进行哈希运算得到第二哈希结果，对所述第一哈希结果和所述第二哈希结果进行异或计算得到异或结果；
步骤b2：所述硬件钱包将所述异或结果的前16字节作为加解密运行的初始向量；根据密钥协商算法使用保存的验证数据和硬件钱包公钥进行密钥协商得到设备密文并保存，将所述设备密文的前16字节数据作为第一密钥；
步骤b3：所述硬件钱包使用所述第一密钥和所述初始向量对所述绑定指令中的终端哈希值的密文进行解密得到第一解密结果；根据所述授权码、验证数据、硬件钱包公钥进行计算得到设备哈希值。
优选地，所述根据所述授权码、验证数据、硬件钱包公钥进行计算得到设备哈希值，具体为：将所述授权码、所述验证数据、所述硬件钱包公钥顺序拼接得到拼接值，对拼接值进行哈希运算得到设备哈希值。
根据本发明的另外一个方面，提供一种硬件钱包绑定授权的装置，包括：
第一判断模块，用于当硬件钱包接收到终端发送的指令时，判断指令的类型，如为查询绑定状态指令则触发第二判断模块，如为生成授权码指令则触发第三判断模块，如为绑定指令则触发第四判断模块；
所述第二判断模块，用于判断判断内部保存的验证数据存在性标志的值，如为第一预设数据则将绑定对象设置为空，将授权状态设为允许生成授权码，触发第一返回模块；如为第二预设数据则触发判断设置模块；
所述判断设置模块，用于判断查询绑定状态指令中的验证数据和保存的验证数据是否一致，是则将绑定对象设置为与所述硬件钱包对应的终端，触发第一返回模块，否则将绑定对 象设置为其他终端，触发第一返回模块；
所述第一返回模块，用于根据绑定对象和保存的硬件钱包证书组织命令响应数据并返回给所述终端，触发所述第一判断模块；
所述第三判断模块，用于判断授权状态是否为允许生成状态码，是则触发生成设置模块，否则给所述终端返回错误信息，触发所述第一判断模块；
所述生成设置模块，用于生成授权码并缓存和显示，将授权状态设为不能再生成授权码，将硬件钱包状态设为未绑定，并给终端返回成功信息，触发所述第一判断模块；
所述第四判断模块，用于判断硬件钱包状态是否为未绑定，是则获取缓存的授权码，触发第一验证模块，否则获取保存的授权码，触发第二验证模块；
所述第一验证模块，用于使用获取的授权码对所述绑定指令进行验证，如验证成功则触发保存设置模块，如验证失败则给终端返回验证失败信息，触发所述第一判断模块；
所述保存设置模块，用于保存所述绑定指令中的验证数据和缓存的授权码，将验证数据存在性标志的值设为第二预定数据，并给所述终端返回授权成功信息，触发所述第一判断模块；
所述第二验证模块，用于使用获取的授权码对所述绑定指令进行验证，如验证成功则触发判断保存模块，如验证失败则给终端返回验证失败信息，触发所述第一判断模块；
所述判断保存模块，用于根据所述绑定指令判断当前连接的终端是否为与所述硬件钱包对应的终端，是则给所述终端返回授权成功过信息，触发所述第一判断模块，否则保存所述绑定指令中的验证数据，将验证数据存在性标志的值设为第二预定数据，并给所述终端返回授权成功信息，触发所述第一判断模块。
优选地，所述保存设置模块还用于将硬件钱包与终端的绑定状态码设为预定值；
所述装置还包括判断签名模块，用于当所述第一判断模块判断接收到终端发送的指令的类型为签名指令时，判断硬件钱包与终端绑定的状态码是否为预定值，是则根据所述签名指令进行签名操作，触发所述第一判断模块，否则给所述终端返回错误信息，触发所述第一判断模块。
优选地，所述装置还包括：第一获取模块，用于从预置缓存中获取验证数据存在性标志的值。
优选地，所述生成设置模块，用于生成授权码包括：所述生成设置模块用于生成预设长度的随机数，根据随机数和预设字符编码表生成检索码；将检索码的值顺序拼接组成授权码。
优选地，所述装置还包括第五判断模块，用于当所述第一判断模块判断指令的类型为绑定指令时，判断所述绑定指令是否合法，是则触发所述第四判断模块，否则给所述终端返回错误信息，触发所述第一判断模块。
优选地，所述第五判断模块具体用于当所述第一判断模块判断指令的类型为绑定指令时，判断所述绑定指令中的第三字节数据是否为第一预设值或第二预设值、且判断第四字节数据是否为第三预设值，如判断均为是则触发所述第四判断模块，否则给所述终端返回错误信息，触发所述第一判断模块。
优选地，所述判断保存模块具体用于判断所述绑定指令中的第三字节数据是否为第二预设值，是则给所述终端返回授权成功过信息，否则保存所述绑定指令中的验证数据，将验证数据存在性标志的值设为第二预定数据，并给所述终端返回授权成功信息，触发所述第一判断模块。
优选地，所述生成设置模块用于将所述硬件钱包状态设为未绑定，具体为时：所述生成设置模块用于将授权码标记设为预设值；
所述第四判断模块具体用于判断授权码标记是否为预设值，是则获取缓存的授权码，触发第一验证模块，否则获取保存的授权码，触发第二验证模块。
优选地，所述第一验证模块，包括：
计算单元，用于根据授权码对所述绑定指令中的终端哈希值的密文进行计算得到第一解 密结果；根据授权码、验证数据、硬件钱包公钥进行计算得到设备哈希值；
第一判断单元，用于判断所述设备哈希值与所述第一解密结果是否相等，是则验证成功，触发保存设置模块，否则验证失败，给终端返回验证失败信息，触发所述第一判断模块；
所述第二验证模块，包括：
计算单元，用于根据授权码对所述绑定指令中的终端哈希值的密文进行计算得到第一解密结果；根据授权码、验证数据、硬件钱包公钥进行计算，得到设备哈希值；
第二判断单元，用于判断所述设备哈希值与所述第一解密结果是否相等，是则验证成功，触发判断保存模块，否则验证失败，给终端返回验证失败信息，触发所述第一判断模块。
优选地，所述计算单元包括：
第一计算子单元，用于对授权码进行哈希运算得到第一哈希结果，对预置常数进行哈希运算得到第二哈希结果，对所述第一哈希结果和所述第二哈希结果进行异或计算，得到异或结果；
解密协商子单元，用于将所述异或结果的前16字节作为加解密运行的初始向量；根据密钥协商算法使用保存的验证数据和硬件钱包公钥进行密钥协商得到设备密文并保存，将所述设备密文的前16字节数据作为第一密钥；
解密计算子单元，用于使用所述第一密钥和所述初始向量对所述绑定指令中的终端哈希值的密文进行解密得到第一解密结果；根据所述授权码、验证数据、硬件钱包公钥进行计算得到设备哈希值。
优选地，所述解密计算子单元用于根据授权码、验证数据、硬件钱包公钥进行计算得到设备哈希值，具体为：所述解密计算子单元用于将所述授权码、所述验证数据、所述硬件钱包公钥顺序拼接得到拼接值，对拼接值进行哈希运算得到设备哈希值。
根据本发明，将终端与硬件钱包一一对应绑定，若硬件钱包需要连接新的终端则必须先通过授权码判断用户是否授权该终端与硬件钱包进行连接，如授权，则允许新的终端与该硬件钱包进行连接，保证了硬件钱包丢失时或未授权时用户资产的安全性。
附图说明
图1为根据本发明实施例的一种硬件钱包绑定授权的方法的流程图；
图2和图3为根据本发明实施例二的一种硬件钱包绑定授权的方法的流程图；
图4为根据本发明实施例三的一种硬件钱包绑定授权的装置的方框图。
具体实施方式
下面将结合本发明的附图，对本发明的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域的技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
实施例一：
本发明实施例一提供一种硬件钱包绑定授权的方法，如图1所示，包括：
步骤S1：当硬件钱包接收到终端发送的指令时，判断指令的类型，如为查询绑定状态指令则执行步骤S2，如为生成授权码指令则执行步骤S5，如为绑定指令则执行步骤S7；
步骤S2：硬件钱包判断内部保存的验证数据存在性标志的值，如为第一预设数据则将绑定对象设置为空，将授权状态设为允许生成授权码，执行步骤S4；如为第二预设数据则执行步骤S3；
优选地，在本实施例一中，步骤S2之前还包括：硬件钱包从预置缓存中获取验证数据存在性标志的值；
步骤S3：硬件钱包判断查询绑定状态指令中的验证数据和保存的验证数据是否一致，是 则将绑定对象设置为与硬件钱包对应的终端，执行步骤S4，否则将绑定对象设置为其他终端，执行步骤S4；
优选地，本实施例一中的验证数据可以为终端公钥或者其他数据；
步骤S4：硬件钱包根据绑定对象和保存的硬件钱包证书组织命令响应数据并返回给终端，返回步骤S1；
步骤S5：硬件钱包判断授权状态是否为允许生成状态码，是则执行步骤S6，否则给终端返回错误信息，返回步骤S1；
步骤S6：硬件钱包生成授权码并缓存和显示，将授权状态设为不能再生成授权码，将硬件钱包状态设为未绑定，并给终端返回成功信息，返回步骤S1；
具体地，在本实施例一中，硬件钱包生成授权码包括：硬件钱包生成预设长度的随机数，根据随机数和预设字符编码表生成检索码；将检索码的值顺序拼接组成授权码；
优选地，将硬件钱包状态设为未绑定，具体为：硬件钱包将授权码标记设为预设值；
步骤S7：硬件钱包判断硬件钱包状态是否为未绑定，是则获取缓存的授权码，执行步骤S8，否则获取保存的授权码，执行步骤S10；
具体地，步骤S7包括：硬件钱包判断授权码标记是否为预设值，是则获取缓存的授权码，执行步骤S8，否则获取保存的授权码，执行步骤S10；
优选地，步骤S7之前还包括：硬件钱包判断绑定指令是否合法，是则执行步骤S7，否则给终端返回错误信息，返回步骤S1；
其中，硬件钱包判断绑定指令是否合法，具体为：硬件钱包判断绑定指令中的第三字节数据是否为第一预设值或第二预设值、且判断第四字节数据是否为第三预设值，如判断均为是则绑定指令合法，否则绑定指令不合法；
步骤S8：硬件钱包使用获取的授权码对绑定指令进行验证，如验证成功则执行步骤S9，如验证失败则给终端返回验证失败信息，返回步骤S1；
具体地，在本实施例一中，硬件钱包使用获取的授权码对绑定指令进行验证，包括：
步骤A1：硬件钱包根据授权码对绑定指令中的终端哈希值的密文进行计算得到第一解密结果；根据授权码、验证数据、硬件钱包公钥进行计算得到设备哈希值；
本实施例一中的步骤A1包括：
步骤b1：硬件钱包对授权码进行哈希运算得到第一哈希结果，对预置常数进行哈希运算得到第二哈希结果，对第一哈希结果和第二哈希结果进行异或计算得到异或结果；
步骤b2：硬件钱包将异或结果的前16字节作为加解密运行的初始向量；根据密钥协商算法使用保存的验证数据和硬件钱包公钥进行密钥协商得到设备密文并保存，将设备密文的前16字节数据作为第一密钥；
例如，在本实施例一中，硬件钱包将异或结果的前16字节作为AES加解密运行的初始向量；
步骤b3：硬件钱包使用第一密钥和初始向量对绑定指令中的终端哈希值的密文进行解密得到第一解密结果；根据授权码、验证数据、硬件钱包公钥进行计算得到设备哈希值；
在本实施例一中，根据授权码、验证数据、硬件钱包公钥进行计算得到设备哈希值，具体为：将授权码、验证数据、硬件钱包公钥顺序拼接得到拼接值，对拼接值进行哈希运算得到设备哈希值；
步骤A2：硬件钱包判断设备哈希值与第一解密结果是否相等，是则验证成功，否则验证失败；
步骤S9：硬件钱包保存绑定指令中的验证数据和缓存的授权码，将验证数据存在性标志的值设为第二预定数据，并给终端返回授权成功信息，返回步骤S1；
步骤S10：硬件钱包使用获取的授权码对绑定指令进行验证，如验证成功则执行步骤S11，如验证失败则给终端返回验证失败信息，返回步骤S1；
在本实施例一中，步骤S10的实现与步骤S8一致，在此不再赘述；
步骤S11：硬件钱包根据绑定指令判断当前连接的终端是否为与硬件钱包对应的终端，是则给终端返回授权成功过信息，返回步骤S1，否则保存绑定指令中的验证数据，将验证数据存在性标志的值设为第二预定数据，并给终端返回授权成功信息，返回步骤S1；
在本实施例一中，步骤S11包括：硬件钱包判断绑定指令中的第三字节数据是否为第二预设值，是则给终端返回授权成功过信息，返回步骤S1，否则保存绑定指令中的验证数据，将验证数据存在性标志的值设为第二预定数据，并给终端返回授权成功信息，返回步骤S1。
优选地，在本实施例一中，只要授权成功则用户就可使用硬件钱包进行操作(例如签名等)，即步骤S9和步骤S11还包括：硬件钱包将硬件钱包与终端的绑定状态码设为预定值；相应的，步骤S1还包括：当硬件钱包判断接收到终端发送的指令的类型为签名指令时，硬件钱包判断硬件钱包与终端绑定的状态码是否为预定值，是则根据签名指令进行签名操作，返回步骤S1，否则给终端返回错误信息。
实施例二：
根据本发明的实施例二，提供了一种硬件钱包绑定授权的方法，如图2和图3所示，该方法包括：
步骤101：当硬件钱包接收到终端发送的指令时，判断指令的类型，如为查询绑定状态指令在执行步骤102，如为生成授权码指令在执行步骤112，如为绑定指令则执行步骤118，如为签名指令则执行步骤143；
具体地，在本实施例二中，硬件钱包判断接收到的指令中的第二个字节数据，如为0x71则指令的类型为查询绑定状态指令；如为0x72指令的类型为生成授权码指令；如为0x73则指令的类型为绑定指令；
在本实施例二中，硬件钱包接收到指令后首先将指令保存在APDU缓存中，然后在进行处理；
步骤102：硬件钱包从查询绑定状态指令中获取验证数据：
具体地，在本实施例二中，步骤102包括：硬件钱包将接收到的查询绑定状态指令保存在APDU缓存中，并从APDU缓存的第5字节开始获取65个字节数据作为验证数据，并存储在第一缓存区中；例如，本实施例二中的验证数据可以为终端公钥；
步骤103：硬件钱包从预置缓存区中获取验证数据存在性标志；
优选的，在本实施例二中，步骤103之前还包括：硬件钱包判断预置缓存中是否有数据，是则执行步骤103，否则报错；
步骤104：硬件钱包从预置缓存区中获取硬件钱包证书并存储到第二缓存区中；
在本实施例二中，硬件钱包证书中包括硬件钱包公钥；
步骤105：硬件钱包判断验证数据存在性标志的值，如为第一预定数据则执行步骤106，如为第二预定数据则执行步骤108；
优选地，第一预定数据为0x0000；第二预定数据为0x5AA5；
步骤106：硬件钱包设置绑定对象设置为空；
例如，在本实施例二中，硬件钱包将绑定对象的值设置为0x00；
步骤107：硬件钱包将授权状态设置为允许生成授权码，执行步骤111；
在本实施例二中，硬件钱包将授权状态设置为0xA5；
步骤108：硬件钱包判断查询绑定状态指令中的验证数据与保存的验证数据是否相等，是则执行步骤109，否则执行步骤110；
步骤109：硬件钱包设置绑定对象设置为与硬件钱包对应的终端，执行步骤111；
例如，在本实施例二中，硬件钱包将绑定对象的值设置为0x55；
步骤110：硬件钱包将绑定对象设置为其它终端，执行步骤111；
例如，在本实施例二中，硬件钱包将绑定对象的值设置为0xAA；
步骤111：硬件钱包根据绑定对象和硬件钱包证书组织命令响应数据并返回给终端，返 回步骤101；
在本实施例二中，终端从接收到的响应数据中获取绑定对象的值，如为0x00则硬件钱包未绑定新设备，终端给硬件钱包设备发送绑定指令；如为0x55则硬件钱包绑定的设备就是当前终端，如为0xAA则硬件钱包绑定了其它终端，终端给硬件钱包发送生成授权码指令；
在本实施例二中，如终端接收到响应数据后，解析响应数据获知绑定对象为空则会给硬件钱包下发生成授权码指令，如解析响应数据获知绑定对象为与该硬件钱包对应的终端或其他终端，则会给硬件钱包下发绑定指令；
步骤112：硬件钱包判断授权状态是否为允许生成授权码，是则执行步骤113，否则给终端返回错误信息；
例如，该步骤中硬件钱包判断授权状态是否为0xA5，是则执行步骤113，否则给终端返回错误信息；优选的，错误信息为9000；
步骤113：硬件钱包生成8个字节的随机数，根据随机数和预设字符编码表生成检索码；
在本实施例二中，硬件钱包根据随机数和预设字符编码表生成检索码包括：硬件钱包对随机数的第n字节在预设字符编码表中所对应的字符编码值模32得到的索引作为SEED的检索码；预设字符编码表为以下字符编码RANDOM_SEED(0～9，A-Z中去除了'0'、'1'、'I'、'O')共32个；
步骤114：硬件钱包将检索码的值顺序拼接组成的授权码并缓存；
在本实施例二中，授权码缓存后如发生掉电，则缓存的授权码将被清除；
步骤115：硬件钱包显示授权码；
在本实施例二中，用户将硬件钱包显示的授权码记录在纸上，并安全保存，等硬件钱包绑定当前设备或其他设备时，用户将保存记录的授权码输入到终端，终端根据授权码计算终端数据并将其发送给硬件钱包，硬件钱包通过缓存或保存的授权码对接收到的终端数据进行验证；
步骤116：硬件钱包将授权状态设置为不能再生成授权码；
例如，在本实施例二中，步骤116中硬件钱包将授权状态设置为0x5A；
步骤117：硬件钱包将授权码标记设置为硬件钱包第一次绑定设备，并给终端返回成功信息，返回步骤101：
具体地，在本实施例二中，硬件钱包将授权码标记设置为0xA5；
步骤118：硬件钱包根据绑定指令中的第三字节判断是否为绑定设备操作或验证设备操作，是则执行步骤119，否则设置状态码，根据设置的状态码给终端返回错误信息；
优选的，步骤118还包括：硬件钱包判断绑定指令的第四字节数据是否为0；
具体地，硬件钱包判断绑定指令的第三字节的值，如为0x00或0x80则终端为绑定设备操作或验证设备操作；设置的状态码为6a86，表示P1、P2的值错误；
步骤119：硬件钱包根据授权码标记判断硬件钱包是否为第一次绑定设备用，是则获取缓存的授权码，执行步在120，否则获取保存的授权码，执行步骤131；
具体地，在本实施例二中，硬件钱包判断授权码标记是否为0xA5，是则可以直接使用缓存的授权码，执行步在120，否则获取保存的授权码，执行步骤120；在本实施例二中，授权码保存后如发生掉电，则保存的授权码在下次硬件钱包开机后可以继续使用；
步骤120：硬件钱包对授权码进行哈希运算得到第一哈希结果，对预置常数进行哈希运算得到第二哈希结果；
例如，本实施例二中的预置常数为0x62 0x69 0x6e 0x64 0x69 0x6e 0x67 0x43 0x6f 0x64 0x65；
步骤121：硬件钱包对第一哈希结果和第二哈希结果进行异或计算，得到异或结果；
步骤122：硬件钱包将异或结果的前16字节作为AES加解密运行的初始向量；
步骤123：硬件钱包获取验证数据，根据密钥协商算法使用验证数据和硬件钱包公钥进行密钥协商得到设备密文并保存，将设备密文的前16字节数据作为第一密钥；
优选地，硬件钱包将APDU缓存中的第6到70字节处的数据作为是验证数据；密钥协商算法具体为ECDH；
在本实施例二中，步骤122与步骤123的顺序可调换；
步骤124：硬件钱包使用第一密钥和初始向量对APDU缓存中的终端哈希值的密文进行解密得到第一解密结果；
具体地，终端哈希值的密文位于于APDU缓存的第70字节之后的32字节；
步骤125：硬件钱包根据授权码、验证数据、硬件钱包公钥进行计算设备哈希值；
在本实施例二中，计算设备哈希值具体为：将授权码、验证数据、硬件钱包公钥顺序拼接得到拼接值，对拼接值进行哈希运算得到设备哈希值；
本实施例二中的步骤124与步骤125的顺序可调换；
步骤126：硬件钱包判断设备哈希值与第一解密结果是否相等，是则执行步骤127，否则执行步骤130；
步骤127：硬件钱包将APDU缓存区中的第一字节设置为验证成功信息：
具体地，硬件钱包将APDU缓存区中的第一字节设置为0x5A；
步骤128：硬件钱包保存授权码和绑定指令中的验证数据，将验证数据存在性标志的值设为第二预定数据，执行步骤129；
具体地，在本实施例二中，将验证数据存在性标志的值设为0x5AA5；
步骤129：硬件钱包通过屏幕提示授权成功，并将APDU缓存区中的验证通过信息和状态码返回给终端，返回步骤101；
具体地，硬件钱包通过屏幕提示授权成功为：硬件钱包在屏幕上显示授权成功提示信息；
例如，本实施例二中的状态码为9000；
步骤130：硬件钱包将APDU缓存区中的第一字节设置为验证失败，通过屏幕提示授权失败并给终端返回验证失败信息，返回步骤101；
在本实施例二中，硬件钱包APDU缓存区的第一字节设置为验证通过，具体为：硬件钱包APDU缓存区的第一字节数据设置为0xA5；
具体地，硬件钱包通过屏幕提示授权失败为：硬件钱包在屏幕上显示授权失败提示信息；
步骤131：硬件钱包对授权码进行哈希运算得到第一哈希结果，对预置常数进行哈希运算得到第二哈希结果；
例如，本实施例二中的预置常数为0x62 0x69 0x6e 0x64 0x69 0x6e 0x67 0x43 0x6f 0x64 0x65；
步骤132：硬件钱包对第一哈希结果和第二哈希结果进行异或计算，得到异或结果；
步骤133：硬件钱包将异或结果的前16字节作为AES加解密运行的初始向量；
步骤134：硬件钱包获取验证数据，根据密钥协商算法使用验证数据和硬件钱包公钥进行密钥协商，得到设备密文并保存，将设备密文的前16字节数据作为第一密钥；
优选地，硬件钱包将APDU缓存中的第6到70字节处的数据作为是验证数据；密钥协商算法具体为ECDH；
在本实施例二中，步骤133与步骤134的顺序可调换；
步骤135：硬件钱包使用第一密钥和初始向量对APDU缓存中的终端哈希值的密文进行解密得到第一解密结果；
具体地，终端哈希值的密文位于于APDU缓存的第70字节之后的32字节；
步骤136：硬件钱包根据授权码、验证数据、硬件钱包公钥进行计算设备哈希值；
在本实施例二中，计算设备哈希值具体为：将授权码、验证数据、硬件钱包公钥顺序拼接得到拼接值，对拼接值进行哈希运算，得到设备哈希值；
本实施例二中的步骤136与步骤137的顺序可调换；
步骤137：硬件钱包判断设备哈希值与第一解密结果是否相等，是则执行步骤138，否则执行步骤142；
步骤138：硬件钱包将APDU缓存区中的第一字节设置为验证成功信息：
具体地，硬件钱包将APDU缓存区中的第一字节设置为0x5A；
步骤139：硬件钱包根据绑定指令中的第三字节数据判断当前连接的终端是否为与硬件钱包对应的终端，是则执行步骤141，否则执行步骤140；
具体地，硬件钱包判断绑定指令中的第三字节数据是否为0x80，是则终端为绑定设备操作，否则终端不为绑定设备操作；
步骤140：硬件钱包保存绑定指令中的验证数据，将验证数据存在性标志的值设为第二预定数据，执行步骤141；
具体地，在本实施例二中，将验证数据存在性标志的值设为0x5AA5；
步骤141：硬件钱包通过屏幕提示授权成功，并将APDU缓存区中的验证通过信息和状态码返回给终端，返回步骤101；
具体地，硬件钱包通过屏幕提示授权成功为：硬件钱包在屏幕上显示授权成功提示信息；
例如，本实施例二中的状态码为9000；
步骤142：硬件钱包将APDU缓存区中的第一字节设置为验证失败，通过屏幕提示授权失败并给终端返回验证失败信息，返回步骤101；
在本实施例二中，硬件钱包APDU缓存区的第一字节设置为验证通过，具体为：硬件钱包APDU缓存区的第一字节数据设置为0xA5；
具体地，硬件钱包通过屏幕提示授权失败为：硬件钱包在屏幕上显示授权失败提示信息；
步骤143：硬件钱包判断硬件钱包与终端绑定的状态码是否为预定值，是则使用硬件钱包私钥对签名指令中的待签名数据进行签名并将签名结果返回给终端，返回步骤101；否则给终端返回错误信息，返回准备101。
本发明技术方案将终端与硬件钱包一一对应绑定，若硬件钱包需要连接终端则必须通过授权码判断用户是否授权该终端与硬件钱包进行连接，如授权则允许该终端与该硬件钱包进行连接，保证了硬件钱包丢失时用户资产的安全性。
实施例三：
根据本发明实施例三，提供一种硬件钱包绑定授权的装置，如图4所示，其包括：
第一判断模块30，用于当硬件钱包接收到终端发送的指令时，判断指令的类型，如为查询绑定状态指令则触发第二判断模块31，如为生成授权码指令则触发第三判断模块34，如为绑定指令则触发第四判断模块36；
第二判断模块31，用于判断判断内部保存的验证数据存在性标志的值，如为第一预设数据则将绑定对象设置为空，将授权状态设为允许生成授权码，触发第一返回模块33；否则触发判断设置模块32；
判断设置模块32，用于判断查询绑定状态指令中的验证数据和保存的验证数据是否一致，是则将绑定对象设置为与硬件钱包对应的终端，触发第一返回模块33，否则将绑定对象设置为其他终端，触发第一返回模块33；
第一返回模块33，用于根据绑定对象和保存的硬件钱包证书组织命令响应数据并返回给终端，触发第一判断模块30；
第三判断模块34，用于判断授权状态是否为允许生成状态码，是则触发生成设置模块35，否则给终端返回错误信息，触发第一判断模块30；
生成设置模块35，用于生成授权码并缓存和显示，将授权状态设为不能再生成授权码，将硬件钱包状态设为未绑定，并给终端返回成功信息，触发第一判断模块30；
具体地，在本实施例三中，生成设置模块35，用于生成授权码包括：生成设置模块35用于生成预设长度的随机数，根据随机数和预设字符编码表生成检索码；将检索码的值顺序拼接组成授权码；
第四判断模块36，用于判断硬件钱包状态是否为未绑定，是则获取缓存的授权码，触发 第一验证模块37，否则获取保存的授权码，触发第二验证模块39；
第一验证模块37，用于使用获取的授权码对绑定指令进行验证，如验证成功则触发保存设置模块38，如验证失败则给终端返回验证失败信息，触发第一判断模块30；
保存设置模块38，用于保存绑定指令中的验证数据和缓存的授权码，将验证数据存在性标志的值设为第二预定数据，并给终端返回授权成功信息，触发第一判断模块30；
第二验证模块39，用于使用获取的授权码对绑定指令进行验证，如验证成功则判断保存模块40，如验证失败则给终端返回验证失败信息，触发第一判断模块30；
判断保存模块40，用于根据绑定指令判断当前连接的终端是否为与硬件钱包对应的终端，是则给终端返回授权成功过信息，触发第一判断模块30，否则保存绑定指令中的验证数据，将验证数据存在性标志的值设为第二预定数据，并给终端返回授权成功信息，触发第一判断模块30。
在本实施例三中，保存设置模块38还用于将硬件钱包与终端的绑定状态码设为预定值；
相应的，装置还包括判断签名模块，用于当第一判断模块30判断接收到终端发送的指令的类型为签名指令时，判断硬件钱包与终端绑定的状态码是否为预定值，是则根据签名指令进行签名操作，触发第一判断模块，否则给终端返回错误信息，触发第一判断模块。
本实施例三中的装置还包括：第一获取模块，用于从预置缓存中获取验证数据存在性标志的值。
本实施例三中的装置还包括第五判断模块，用于当第一判断模块30判断指令的类型为绑定指令时，判断绑定指令是否合法，是则触发第四判断模块36，否则给终端返回错误信息，触发第一判断模块30。
在本实施例三中，第五判断模块具体用于当第一判断模块30判断指令的类型为绑定指令时，判断绑定指令中的第三字节数据是否为第一预设值或第二预设值、且判断第四字节数据是否为第三预设值，如判断均为是则触发第四判断模块36，否则给终端返回错误信息，触发第一判断模块30。
在本实施例三中，判断保存模块40具体用于判断绑定指令中的第三字节数据是否为第二预设值，是则给终端返回授权成功过信息，否则保存绑定指令中的验证数据，将验证数据存在性标志的值设为第二预定数据，并给终端返回授权成功信息，触发第一判断模块。
优选地，生成设置模块35用于将硬件钱包状态设为未绑定，具体为：生成设置模块35用于将授权码标记设为预设值；则第四判断模块36具体用于判断授权码标记是否为预设值，是则获取缓存的授权码，触发第一验证模块37，否则获取保存的授权码，触发第二验证模块39。
具体地，在本实施例三中，第一验证模块37，包括：
计算单元，用于根据授权码对绑定指令中的终端哈希值的密文进行计算得到第一解密结果；根据授权码、验证数据、硬件钱包公钥进行计算得到设备哈希值；
其中，计算单元包括：
第一计算子单元，用于对授权码进行哈希运算得到第一哈希结果，对预置常数进行哈希运算得到第二哈希结果，对第一哈希结果和第二哈希结果进行异或计算，得到异或结果；
解密协商子单元，用于将异或结果的前16字节作为加解密运行的初始向量；根据密钥协商算法使用保存的验证数据和硬件钱包公钥进行密钥协商，得到设备密文并保存，将设备密文的前16字节数据作为第一密钥；
例如，在本实施例三中，解密协商子单元用于将异或结果的前16字节作为AES加解密运行的初始向量；
解密计算子单元，用于使用第一密钥和初始向量对绑定指令中的终端哈希值的密文进行解密得到第一解密结果；根据授权码、验证数据、硬件钱包公钥进行计算，得到设备哈希值；
在本实施例三中，解密计算子单元用于根据授权码、验证数据、硬件钱包公钥进行计算得到设备哈希值，具体为：解密计算子单元用于将授权码、验证数据、硬件钱包公钥顺序拼 接得到拼接值，对拼接值进行哈希运算，得到设备哈希值；
第一判断单元，用于判断设备哈希值与第一解密结果是否相等，是则验证成功，触发保存设置模块38，否则验证失败，给终端返回验证失败信息，触发第一判断模块30；
第二验证模块39，包括：
计算单元，用于根据授权码对绑定指令中的终端哈希值的密文进行计算得到第一解密结果；根据授权码、验证数据、硬件钱包公钥进行计算，得到设备哈希值；
本实施例三中第一验证模块37中的计算单元与第二验证模块39中的计算单元实现过程相同，在此不再赘述；
第二判断单元，用于判断设备哈希值与第一解密结果是否相等，是则验证成功，触发判断保存模块，否则验证失败，给终端返回验证失败信息，触发第一判断模块。
以上所述，仅为本发明较佳的具体实施方式，但本发明的保护范围并不局限于此，本领域的技术人员在本发明公开的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应该以权利要求书的保护范围为准。

Claims (20)

  1. 一种硬件钱包绑定授权的方法，其特征在于，包括如下步骤：
    S1)当硬件钱包接收到终端发送的指令时，判断指令的类型，如为查询绑定状态指令则执行步骤S2，如为生成授权码指令则执行步骤S5，如为绑定指令则执行步骤S7；
    S2)所述硬件钱包判断内部保存的验证数据存在性标志的值，如为第一预设数据则将绑定对象设置为空，将授权状态设为允许生成授权码，执行步骤S4；如为第二预设数据则执行步骤S3；
    S3)所述硬件钱包判断查询绑定状态指令中的验证数据和保存的验证数据是否一致，是则将绑定对象设置为与所述硬件钱包对应的终端，执行步骤S4，否则将绑定对象设置为其他终端，执行步骤S4；
    S4)所述硬件钱包根据绑定对象和保存的硬件钱包证书组织命令响应数据并返回给所述终端，返回步骤S1；
    S5)所述硬件钱包判断授权状态是否为允许生成状态码，是则执行步骤S6，否则给所述终端返回错误信息，返回步骤S1；
    S6)所述硬件钱包生成授权码并缓存和显示，将授权状态设为不能再生成授权码，将硬件钱包状态设为未绑定，并给终端返回成功信息，返回步骤S1；
    S7)所述硬件钱包判断硬件钱包状态是否为未绑定，是则获取缓存的授权码，执行步骤S8，否则获取保存的授权码，执行步骤S10；
    S8)所述硬件钱包使用获取的授权码对所述绑定指令进行验证，如验证成功则执行步骤S9，如验证失败则给终端返回验证失败信息，返回步骤S1；
    S9)所述硬件钱包保存所述绑定指令中的验证数据和缓存的授权码，将验证数据存在性标志的值设为第二预定数据，并给所述终端返回授权成功信息，返回步骤S1；
    S10)所述硬件钱包使用获取的授权码对所述绑定指令进行验证，如验证成功则执行步骤S11，如验证失败则给终端返回验证失败信息，返回步骤S1；以及
    S11)所述硬件钱包根据所述绑定指令判断当前连接的终端是否为与所述硬件钱包对应的终端，是则给所述终端返回授权成功过信息，返回步骤S1，否则保存所述绑定指令中的验证数据，将验证数据存在性标志的值设为第二预定数据，并给所述终端返回授权成功信息，返回步骤S1。
  2. 如权利要求1所述的方法，其特征在于，所述步骤S9和所述步骤S11还包括：所述硬件钱包将硬件钱包与终端的绑定状态码设为预定值；
    所述步骤S1还包括：当硬件钱包判断接收到终端发送的指令的类型为签名指令时，所述硬件钱包判断硬件钱包与终端绑定的状态码是否为预定值，是则根据所述签名指令进行签名操作，返回步骤S1，否则，给所述终端返回错误信息。
  3. 如权利要求1所述的方法，其特征在于，所述硬件钱包生成授权码包括：
    所述硬件钱包生成预设长度的随机数，根据所述随机数和预设字符编码表生成检索码；将检索码的值顺序拼接组成授权码。
  4. 如权利要求1所述的方法，其特征在于，所述步骤S7之前还包括：所述硬件钱包判断所述绑定指令是否合法，是则执行步骤S7，否则给所述终端返回错误信息，返回步骤S1。
  5. 如权利要求4所述的方法，其特征在于，所述硬件钱包判断所述绑定指令是否合法，具体为：所述硬件钱包判断所述绑定指令中的第三字节数据是否为第一预设值或第二预设值、且判断第四字节数据是否为第三预设值，如判断均为是则所述绑定指令合法，否则所述绑定指令不合法。
  6. 如权利要求5所述的方法，其特征在于，所述步骤S11包括：所述硬件钱包判断所述绑定指令中的第三字节数据是否为第二预设值，是则给所述终端返回授权成功过信息，返回步骤S1，否则保存所述绑定指令中的验证数据，将验证数据存在性标志的值设为第二预定数 据，并给所述终端返回授权成功信息，返回步骤S1。
  7. 如权利要求1所述的方法，其特征在于，所述将硬件钱包状态设为未绑定，具体为：所述硬件钱包将授权码标记设为预设值；
    所述步骤S7包括：所述硬件钱包判断授权码标记是否为预设值，是则获取缓存的授权码，执行步骤S8，否则获取保存的授权码，执行步骤S10。
  8. 如权利要求1所述的方法，其特征在于，所述硬件钱包使用获取的授权码对所述绑定指令进行验证，包括如下步骤：
    A1)所述硬件钱包根据授权码对所述绑定指令中的终端哈希值的密文进行计算，得到第一解密结果；根据所述授权码、验证数据、硬件钱包公钥进行计算，得到设备哈希值；以及
    A2)所述硬件钱包判断所述设备哈希值与所述第一解密结果是否相等，是则验证成功，否则验证失败。
  9. 如权利要求8所述的方法，其特征在于，所述步骤A1包括如下步骤：
    b1)所述硬件钱包对授权码进行哈希运算得到第一哈希结果，对预置常数进行哈希运算得到第二哈希结果，对所述第一哈希结果和所述第二哈希结果进行异或计算，得到异或结果；
    b2)所述硬件钱包将所述异或结果的前16字节作为加解密运行的初始向量；根据密钥协商算法，使用保存的验证数据和硬件钱包公钥进行密钥协商，得到设备密文并保存，将所述设备密文的前16字节数据作为第一密钥；以及
    b3)所述硬件钱包使用所述第一密钥和所述初始向量对所述绑定指令中的终端哈希值的密文进行解密，得到第一解密结果；根据所述授权码、验证数据、硬件钱包公钥进行计算，得到设备哈希值。
  10. 如权利要求9所述的方法，其特征在于，所述根据所述授权码、验证数据、硬件钱包公钥进行计算得到设备哈希值，具体为：将所述授权码、所述验证数据、所述硬件钱包公钥顺序拼接得到拼接值，对拼接值进行哈希运算，得到设备哈希值。
  11. 一种硬件钱包绑定授权的装置，其特征在于，包括：
    第一判断模块，用于当硬件钱包接收到终端发送的指令时，判断指令的类型，如为查询绑定状态指令则触发第二判断模块，如为生成授权码指令则触发第三判断模块，如为绑定指令则触发第四判断模块；
    所述第二判断模块，用于判断判断内部保存的验证数据存在性标志的值，如为第一预设数据则将绑定对象设置为空，将授权状态设为允许生成授权码，触发第一返回模块；如为第二预设数据则触发判断设置模块；
    所述判断设置模块，用于判断查询绑定状态指令中的验证数据和保存的验证数据是否一致，是则将绑定对象设置为与所述硬件钱包对应的终端，触发第一返回模块，否则将绑定对象设置为其他终端，触发第一返回模块；
    所述第一返回模块，用于根据绑定对象和保存的硬件钱包证书组织命令响应数据并返回给所述终端，触发所述第一判断模块；
    所述第三判断模块，用于判断授权状态是否为允许生成状态码，是则触发生成设置模块，否则给所述终端返回错误信息，触发所述第一判断模块；
    所述生成设置模块，用于生成授权码并缓存和显示，将授权状态设为不能再生成授权码，将硬件钱包状态设为未绑定，并给终端返回成功信息，触发所述第一判断模块；
    所述第四判断模块，用于判断硬件钱包状态是否为未绑定，是则获取缓存的授权码，触发第一验证模块，否则获取保存的授权码，触发第二验证模块；
    所述第一验证模块，用于使用获取的授权码对所述绑定指令进行验证，如验证成功则触发保存设置模块，如验证失败则给终端返回验证失败信息，触发所述第一判断模块；
    所述保存设置模块，用于保存所述绑定指令中的验证数据和缓存的授权码，将验证数据存在性标志的值设为第二预定数据，并给所述终端返回授权成功信息，触发所述第一判断模块；
    所述第二验证模块，用于使用获取的授权码对所述绑定指令进行验证，如验证成功则触发判断保存模块，如验证失败则给终端返回验证失败信息，触发所述第一判断模块；以及
    所述判断保存模块，用于根据所述绑定指令判断当前连接的终端是否为与所述硬件钱包对应的终端，是则给所述终端返回授权成功过信息，触发所述第一判断模块，否则保存所述绑定指令中的验证数据，将验证数据存在性标志的值设为第二预定数据，并给所述终端返回授权成功信息，触发所述第一判断模块。
  12. 如权利要求11所述的装置，其特征在于，所述保存设置模块还用于将硬件钱包与终端的绑定状态码设为预定值；
    所述装置还包括判断签名模块，用于当所述第一判断模块判断接收到终端发送的指令的类型为签名指令时，判断硬件钱包与终端绑定的状态码是否为预定值，是则根据所述签名指令进行签名操作，触发所述第一判断模块，否则给所述终端返回错误信息，触发所述第一判断模块。
  13. 如权利要求11所述的装置，其特征在于，所述生成设置模块，用于生成授权码包括：所述生成设置模块用于生成预设长度的随机数，根据随机数和预设字符编码表生成检索码；将检索码的值顺序拼接组成授权码。
  14. 如权利要求11所述的装置，其特征在于，包括第五判断模块，用于当所述第一判断模块判断指令的类型为绑定指令时，判断所述绑定指令是否合法，是则触发所述第四判断模块，否则给所述终端返回错误信息，触发所述第一判断模块。
  15. 如权利要求14所述的装置，其特征在于，所述第五判断模块具体用于当所述第一判断模块判断指令的类型为绑定指令时，判断所述绑定指令中的第三字节数据是否为第一预设值或第二预设值、且判断第四字节数据是否为第三预设值，如判断均为是则触发所述第四判断模块，否则给所述终端返回错误信息，触发所述第一判断模块。
  16. 如权利要求15所述的装置，其特征在于，所述判断保存模块具体用于判断所述绑定指令中的第三字节数据是否为第二预设值，是则给所述终端返回授权成功过信息，否则保存所述绑定指令中的验证数据，将验证数据存在性标志的值设为第二预定数据，并给所述终端返回授权成功信息，触发所述第一判断模块。
  17. 如权利要求11所述的装置，其特征在于，所述生成设置模块用于将所述硬件钱包状态设为未绑定，具体为时：所述生成设置模块用于将授权码标记设为预设值；
    所述第四判断模块具体用于判断授权码标记是否为预设值，是则获取缓存的授权码，触发第一验证模块，否则获取保存的授权码，触发第二验证模块。
  18. 如权利要求11所述的装置，其特征在于，所述第一验证模块，包括：
    计算单元，用于根据授权码对所述绑定指令中的终端哈希值的密文进行计算得到第一解密结果；根据授权码、验证数据、硬件钱包公钥进行计算得到设备哈希值；
    第一判断单元，用于判断所述设备哈希值与所述第一解密结果是否相等，是则验证成功，触发保存设置模块，否则验证失败，给终端返回验证失败信息，触发所述第一判断模块；
    所述第二验证模块，包括：
    计算单元，用于根据授权码对所述绑定指令中的终端哈希值的密文进行计算得到第一解密结果；根据授权码、验证数据、硬件钱包公钥进行计算得到设备哈希值；以及
    第二判断单元，用于判断所述设备哈希值与所述第一解密结果是否相等，是则验证成功，触发判断保存模块，否则验证失败，给终端返回验证失败信息，触发所述第一判断模块。
  19. 如权利要求18所述的装置，其特征在于，所述计算单元包括：
    第一计算子单元，用于对授权码进行哈希运算得到第一哈希结果，对预置常数进行哈希运算得到第二哈希结果，对所述第一哈希结果和所述第二哈希结果进行异或计算得到异或结果；
    解密协商子单元，用于将所述异或结果的前16字节作为加解密运行的初始向量；根据密钥协商算法使用保存的验证数据和硬件钱包公钥进行密钥协商得到设备密文并保存，将所述 设备密文的前16字节数据作为第一密钥；以及
    解密计算子单元，用于使用所述第一密钥和所述初始向量对所述绑定指令中的终端哈希值的密文进行解密得到第一解密结果；根据所述授权码、验证数据、硬件钱包公钥进行计算得到设备哈希值。
  20. 如权利要求19所述的装置，其特征在于，所述解密计算子单元用于根据授权码、验证数据、硬件钱包公钥进行计算得到设备哈希值，具体为：所述解密计算子单元用于将所述授权码、所述验证数据、所述硬件钱包公钥顺序拼接得到拼接值，对拼接值进行哈希运算得到设备哈希值。
PCT/CN2020/102170 2019-09-09 2020-07-15 一种硬件钱包绑定授权的方法及装置 WO2021047281A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US17/606,344 US11863684B2 (en) 2019-09-09 2020-07-15 Hardware wallet binding authorization method and apparatus

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201910849430.3 2019-09-09
CN201910849430.3A CN110610360B (zh) 2019-09-09 2019-09-09 一种硬件钱包绑定授权的方法及装置

Publications (1)

Publication Number Publication Date
WO2021047281A1 true WO2021047281A1 (zh) 2021-03-18

Family

ID=68892482

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2020/102170 WO2021047281A1 (zh) 2019-09-09 2020-07-15 一种硬件钱包绑定授权的方法及装置

Country Status (3)

Country Link
US (1) US11863684B2 (zh)
CN (1) CN110610360B (zh)
WO (1) WO2021047281A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110610360B (zh) * 2019-09-09 2022-03-18 飞天诚信科技股份有限公司 一种硬件钱包绑定授权的方法及装置
WO2024046453A1 (zh) * 2022-09-01 2024-03-07 中国人民银行数字货币研究所 交易方法、硬件钱包开立方法、装置和设备

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105577688A (zh) * 2016-01-30 2016-05-11 飞天诚信科技股份有限公司 一种基于蓝牙设备的绑定方法和装置
CN106910070A (zh) * 2017-02-07 2017-06-30 桂林理工大学 带可见光通信与扫码识别的免密离线支付方法
CN107249170A (zh) * 2017-06-13 2017-10-13 天地融科技股份有限公司 一种蓝牙设备安全通信的方法及系统
CN109670799A (zh) * 2018-11-12 2019-04-23 江苏南大安高区块链应用技术研究院有限公司 一种安全数字货币硬件钱包的实现方法及装置
US20190123901A1 (en) * 2017-10-19 2019-04-25 Autnhive Corporation System and method for generating and depositing keys for multi-point authentication
CN110610360A (zh) * 2019-09-09 2019-12-24 飞天诚信科技股份有限公司 一种硬件钱包绑定授权的方法及装置

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9355393B2 (en) * 2011-08-18 2016-05-31 Visa International Service Association Multi-directional wallet connector apparatuses, methods and systems
US9563891B2 (en) * 2012-07-09 2017-02-07 Google Inc. Systems, methods, and computer program products for integrating third party services with a mobile wallet
US10178164B2 (en) * 2015-08-31 2019-01-08 Visa International Service Association Secure binding of software application to communication device
US10839375B2 (en) * 2016-12-01 2020-11-17 Paypal, Inc. Data security systems configured to detect microcontrollers in physical wallets
CN107330690B (zh) * 2017-06-26 2020-10-09 中国人民银行数字货币研究所 数字货币的应用钱包与银行钱包进行绑定的方法和系统
CN107392579B (zh) * 2017-06-26 2020-10-09 中国人民银行数字货币研究所 数字货币的应用钱包和银行钱包的解绑定方法和系统
CN107480986B (zh) * 2017-08-14 2019-08-09 飞天诚信科技股份有限公司 一种利用硬件实现数字货币钱包的方法及硬件钱包
SG11202007263VA (en) * 2018-02-15 2020-08-28 Gk8 Ltd Cryptocurrency wallet and cryptocurrency account management
CN108810894B (zh) * 2018-05-31 2023-08-25 康键信息技术（深圳）有限公司 终端授权方法、装置、计算机设备和存储介质
US20200013052A1 (en) * 2018-07-05 2020-01-09 Esmart Tech, Inc. Offline cryptocurrency wallet with secure key management
KR101954863B1 (ko) * 2018-07-09 2019-03-06 서울대학교산학협력단 온라인 월렛 장치 및 이의 생성과 검증 방법

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105577688A (zh) * 2016-01-30 2016-05-11 飞天诚信科技股份有限公司 一种基于蓝牙设备的绑定方法和装置
CN106910070A (zh) * 2017-02-07 2017-06-30 桂林理工大学 带可见光通信与扫码识别的免密离线支付方法
CN107249170A (zh) * 2017-06-13 2017-10-13 天地融科技股份有限公司 一种蓝牙设备安全通信的方法及系统
US20190123901A1 (en) * 2017-10-19 2019-04-25 Autnhive Corporation System and method for generating and depositing keys for multi-point authentication
CN109670799A (zh) * 2018-11-12 2019-04-23 江苏南大安高区块链应用技术研究院有限公司 一种安全数字货币硬件钱包的实现方法及装置
CN110610360A (zh) * 2019-09-09 2019-12-24 飞天诚信科技股份有限公司 一种硬件钱包绑定授权的方法及装置

Also Published As

Publication number Publication date
CN110610360B (zh) 2022-03-18
CN110610360A (zh) 2019-12-24
US11863684B2 (en) 2024-01-02
US20220231854A1 (en) 2022-07-21

Similar Documents

Publication Publication Date Title
CN108377190B (zh) 一种认证设备及其工作方法
CN108667608B (zh) 数据密钥的保护方法、装置和系统
CN109688098B (zh) 数据的安全通信方法、装置、设备及计算机可读存储介质
US7373509B2 (en) Multi-authentication for a computing device connecting to a network
US9253162B2 (en) Intelligent card secure communication method
KR20180114182A (ko) 비밀 공유를 위한 타원 곡선 암호를 사용하는 개인용 장치 보안
KR20220117211A (ko) 비접촉식 카드 개인 식별 시스템
WO2021047281A1 (zh) 一种硬件钱包绑定授权的方法及装置
BR112014025959B1 (pt) Dispositivo de entrada de senha e método para autenticar um usuário
CN106850207B (zh) 无ca的身份认证方法和系统
US20120005474A1 (en) Information system and method of identifying a user by an application server
CN110677382A (zh) 数据安全处理方法、装置、计算机系统及存储介质
CN113569223B (zh) 一种离线设备的安全认证方法
CN110955918A (zh) 一种基于RSA加密sha-256数字签名的合同文本保护方法
CN113872770A (zh) 一种安全性验证方法、系统、电子设备及存储介质
KR101001400B1 (ko) 온라인 상호 인증 방법 및 그 시스템
CN106156677A (zh) 身份证读卡方法和系统
CN107548542B (zh) 经强化完整性及安全性的用户认证方法
CN114448607A (zh) 一种基于puf技术的离线设备安全认证系统及实现方法
CN106454826B (zh) 一种ap接入ac的方法和装置
US20170330177A1 (en) Payment terminal authentication
JP2008124987A (ja) 暗号通信装置及び暗号通信システム及び暗号通信方法及びプログラム
CN109660341B (zh) 一种在应用通信中保护数据安全的实现方法及系统
CN108323231B (zh) 一种传输密钥的方法、接收终端和分发终端
WO2021114113A1 (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: 20863869

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 20863869

Country of ref document: EP

Kind code of ref document: A1