Hardware wallet binding authorization method and device

文档序号:1649980 发布日期:2019-12-24 浏览:20次 中文

阅读说明:本技术 一种硬件钱包绑定授权的方法及装置 (Hardware wallet binding authorization method and device ) 是由 陆舟 于华章 于 2019-09-09 设计创作,主要内容包括:本发明公开一种硬件钱包绑定授权的方法及装置,该方法包括:当硬件钱包接收到查询绑定状态指令则判断验证数据存在性标志的值,如为第一预设数据则将绑定对象设置为空,将授权状态设为允许生成授权码;如为第二预设数据则将绑定对象设置为与硬件钱包对应的终端或其他终端;将绑定对象和保存的硬件钱包证书返回给终端;当硬件钱包接收到生成授权码指令时如授权状态为允许生成状态码则生成授权码并缓存和显示,将授权状态设为不能再生成授权码,将硬件钱包状态设为未绑定;当硬件钱包接收到绑定指令则使用获取的授权码对绑定指令进行验证,如验证成功则绑定成功。终端只有通过用户授权才能与硬件钱包进行连接,保证用户资产的安全。(The invention discloses a method and a device for binding and authorizing a hardware wallet, wherein the method comprises the following steps: when the hardware wallet receives a binding state inquiry command, judging the value of a data existence mark, if the value is first preset data, setting a binding object to be null, and setting an authorization state to be an authorization code allowed to be generated; if the binding object is the second preset data, setting the binding object as a terminal corresponding to the hardware wallet or other terminals; returning the binding object and the stored hardware wallet certificate to the terminal; when the hardware wallet receives a command for generating the authorization code, if the authorization state is the permission for generating the status code, the authorization code is generated, cached and displayed, the authorization state is set as the authorization code which can not be generated again, and the hardware wallet status is set as unbound; and when the hardware wallet receives the binding instruction, verifying the binding instruction by using the acquired authorization code, and if the verification is successful, successfully binding. The terminal can be connected with the hardware wallet only through user authorization, and the safety of user assets is guaranteed.)

1. A method of hardware wallet binding authorization, comprising:

step S1: when the hardware wallet receives a command sent by the terminal, judging the type of the command, if the command is a command for inquiring the binding state, executing the step S2, if the command is a command for generating an authorization code, executing the step S5, and if the command is a binding command, executing the step S7;

step S2: the hardware wallet judges the value of the verification data existence flag stored inside, if the value is the first preset data, the binding object is set to be null, the authorization state is set to allow the generation of the authorization code, and step S4 is executed; if the second preset data is the second preset data, executing step S3;

step S3: the hardware wallet judges whether the verification data in the inquiry binding state instruction is consistent with the stored verification data, if so, the binding object is set as a terminal corresponding to the hardware wallet, and a step S4 is executed, otherwise, the binding object is set as other terminals, and a step S4 is executed;

step S4: the hardware wallet organizes the command response data according to the binding object and the saved hardware wallet certificate and returns the command response data to the terminal, and the step returns to step S1;

step S5: the hardware wallet judges whether the authorization state is the permission to generate the state code, if so, the step S6 is executed, otherwise, the error information is returned to the terminal, and the step S1 is returned;

step S6: the hardware wallet generates, caches and displays the authorization code, sets the authorization state as authorization code which cannot be regenerated, sets the hardware wallet state as unbound, returns success information to the terminal, and returns to step S1;

step S7: the hardware wallet judges whether the hardware wallet state is unbound, if so, the cached authorization code is obtained, and step S8 is executed, otherwise, the stored authorization code is obtained, and step S10 is executed;

step S8: the hardware wallet verifies the binding instruction by using the acquired authorization code, if the verification is successful, the step S9 is executed, if the verification is failed, verification failure information is returned to the terminal, and the step S1 is returned;

step S9: the hardware wallet stores the verification data and the cached authorization code in the binding instruction, sets the value of the verification data existence flag as second preset data, returns authorization success information to the terminal, and returns to the step S1;

step S10: the hardware wallet verifies the binding instruction by using the acquired authorization code, if the verification is successful, the step S11 is executed, if the verification is failed, verification failure information is returned to the terminal, and the step S1 is returned;

step S11: and the hardware wallet judges whether the currently connected terminal is the terminal corresponding to the hardware wallet according to the binding instruction, if so, returns authorization success information to the terminal, and returns to the step S1, otherwise, the hardware wallet stores the verification data in the binding instruction, sets the value of the verification data existence flag as second preset data, returns authorization success information to the terminal, and returns to the step S1.

2. The method of claim 1, wherein the steps S9 and S11 further include: the hardware wallet sets a binding state code of the hardware wallet and the terminal as a preset value;

the step S1 further includes: when the hardware wallet judges that the type of the received instruction sent by the terminal is a signature instruction, the hardware wallet judges whether the status code of the binding between the hardware wallet and the terminal is a preset value, if so, the signature operation is carried out according to the signature instruction, the step S1 is returned, otherwise, error information is returned to the terminal.

3. The method of claim 1, wherein the step S2 is preceded by: the hardware wallet obtains the value of the validation data presence flag from a preset cache.

4. The method of claim 1, wherein the hardware wallet generating the authorization code comprises:

the hardware wallet generates a random number with a preset length and generates a retrieval code according to the random number and a preset character coding table; and sequentially splicing the values of the retrieval codes to form the authorization codes.

5. The method of claim 1, wherein the step S7 is preceded by: and the hardware wallet judges whether the binding instruction is legal or not, if so, the step S7 is executed, otherwise, an error message is returned to the terminal, and the step S1 is returned.

6. The method of claim 5, wherein the hardware wallet determines whether the binding instruction is valid by: and the hardware wallet judges whether the third byte data in the binding instruction is a first preset value or a second preset value and judges whether the fourth byte data is a third preset value, if so, the binding instruction is legal, otherwise, the binding instruction is illegal.

7. The method of claim 6, wherein the step S11 includes: and the hardware wallet judges whether the third byte data in the binding instruction is a second preset value, if so, authorization success information is returned to the terminal, the step is returned to S1, otherwise, the verification data in the binding instruction is saved, the value of the verification data existence mark is set as second preset data, authorization success information is returned to the terminal, and the step is returned to S1.

8. The method of claim 1, wherein setting the hardware wallet state as unbound is specifically: the hardware wallet sets an authorization code mark as a preset value;

the step S7 includes: and the hardware wallet judges whether the authorization code mark is a preset value, if so, the cached authorization code is obtained, and the step S8 is executed, otherwise, the stored authorization code is obtained, and the step S10 is executed.

9. The method of claim 1, wherein the hardware wallet verifying the binding instruction using the obtained authorization code comprises:

step A1: the hardware wallet calculates the ciphertext of the terminal hash value in the binding instruction according to the authorization code to obtain a first decryption result; calculating according to the authorization code, the verification data and the hardware wallet public key to obtain a device hash value;

step A2: and the hardware wallet judges whether the hash value of the equipment is equal to the first decryption result, if so, the verification is successful, and otherwise, the verification fails.

10. The method of claim 9, wherein said step a1 comprises:

step b 1: the hardware wallet performs hash operation on the authorization code to obtain a first hash result, performs hash operation on a preset constant to obtain a second hash result, and performs exclusive-or calculation on the first hash result and the second hash result to obtain an exclusive-or result;

step b 2: the hardware wallet takes the first 16 bytes of the XOR result as an initial vector of encryption and decryption operation; performing key agreement by using the stored verification data and a hardware wallet public key according to a key agreement algorithm to obtain and store a device ciphertext, and taking the first 16 bytes of data of the device ciphertext as a first key;

step b 3: the hardware wallet decrypts a ciphertext of a terminal hash value in the binding instruction by using the first key and the initial vector to obtain a first decryption result; and calculating according to the authorization code, the verification data and the hardware wallet public key to obtain the equipment hash value.

11. The method according to claim 10, wherein the calculating according to the authorization code, the verification data, and the hardware wallet public key to obtain the device hash value specifically includes: and sequentially splicing the authorization code, the verification data and the hardware wallet public key to obtain a spliced value, and performing hash operation on the spliced value to obtain an equipment hash value.

12. An apparatus for hardware wallet binding authorization, comprising:

the first judgment module is used for judging the type of the instruction when the hardware wallet receives the instruction sent by the terminal, triggering the second judgment module if the instruction is a binding state inquiry instruction, triggering the third judgment module if the instruction is an authorization code generation instruction, and triggering the fourth judgment module if the instruction is a binding instruction;

the second judging module is used for judging and judging the value of the verification data existence mark stored inside, if the verification data existence mark is first preset data, the binding object is set to be null, the authorization state is set to be allowed to generate an authorization code, and the first returning module is triggered; if the first preset data is the second preset data, triggering a judgment setting module;

the judging and setting module is used for judging whether the verification data in the inquiry binding state instruction is consistent with the stored verification data, if so, the binding object is set as a terminal corresponding to the hardware wallet, and the first returning module is triggered, otherwise, the binding object is set as other terminals, and the first returning module is triggered;

the first returning module is used for organizing command response data according to the binding object and the stored hardware wallet certificate and returning the command response data to the terminal to trigger the first judging module;

the third judging module is used for judging whether the authorization state is a state code allowed to be generated or not, if so, the generating and setting module is triggered, otherwise, error information is returned to the terminal, and the first judging module is triggered;

the generation setting module is used for generating, caching and displaying the authorization code, setting the authorization state as an authorization code which can not be regenerated, setting the hardware wallet state as unbound, returning success information to the terminal, and triggering the first judgment module;

the fourth judging module is used for judging whether the hardware wallet state is unbound or not, if so, the cached authorization code is obtained, and the first verifying module is triggered, otherwise, the stored authorization code is obtained, and the second verifying module is triggered;

the first verification module is configured to verify the binding instruction by using the acquired authorization code, trigger the storage setting module if the verification is successful, and return verification failure information to the terminal if the verification is failed, so as to trigger the first judgment module;

the storage setting module is configured to store the verification data and the cached authorization code in the binding instruction, set a value of a verification data existence flag to be second predetermined data, return authorization success information to the terminal, and trigger the first determining module;

the second verification module is configured to verify the binding instruction by using the obtained authorization code, trigger the judgment and storage module if the verification is successful, and return verification failure information to the terminal if the verification is failed, and trigger the first judgment module;

and the judging and storing module is used for judging whether the currently connected terminal is the terminal corresponding to the hardware wallet according to the binding instruction, if so, returning authorization success information to the terminal to trigger the first judging module, otherwise, storing the verification data in the binding instruction, setting the value of a verification data existence mark as second preset data, returning authorization success information to the terminal, and triggering the first judging module.

13. The apparatus of claim 12, wherein the save settings module is further configured to set a binding status code of the hardware wallet to the terminal to a predetermined value;

the device also comprises a signature judging module, which is used for judging whether a state code bound by the hardware wallet and the terminal is a preset value or not when the first judging module judges that the type of the received instruction sent by the terminal is a signature instruction, if so, the signature judging module carries out signature operation according to the signature instruction and triggers the first judging module, otherwise, the first judging module is triggered by returning error information to the terminal.

14. The apparatus of claim 12, further comprising: and the first acquisition module is used for acquiring the value of the verification data existence mark from the preset cache.

15. The apparatus of claim 12, wherein the generate settings module to generate an authorization code comprises: the generation setting module is used for generating a random number with a preset length and generating a retrieval code according to the random number and a preset character coding table; and sequentially splicing the values of the retrieval codes to form the authorization codes.

16. The apparatus according to claim 12, comprising a fifth determining module, configured to determine whether the binding instruction is legal when the first determining module determines that the type of the instruction is the binding instruction, if so, trigger the fourth determining module, otherwise, return an error message to the terminal, and trigger the first determining module.

17. The apparatus according to claim 16, wherein the fifth determining module is specifically configured to, when the first determining module determines that the type of the instruction is a binding instruction, determine whether third byte data in the binding instruction is a first preset value or a second preset value, and determine whether fourth byte data is a third preset value, if yes, trigger the fourth determining module, otherwise, return an error message to the terminal, and trigger the first determining module.

18. The apparatus according to claim 17, wherein the determining and storing module is specifically configured to determine whether third byte data in the binding instruction is a second preset value, if so, return authorization success information to the terminal, otherwise, store the verification data in the binding instruction, set a value of a verification data existence flag to be second preset data, and return authorization success information to the terminal, thereby triggering the first determining module.

19. The apparatus of claim 12, wherein the generation setting module is to set the hardware wallet state as unbound, and in particular when: the generation setting module is used for setting the authorization code mark as a preset value;

the fourth judging module is specifically configured to judge whether the authorization code flag is a preset value, if so, obtain the cached authorization code, and trigger the first verifying module, and otherwise, obtain the stored authorization code, and trigger the second verifying module.

20. The apparatus of claim 12, wherein the first authentication module comprises:

the computing unit is used for computing the ciphertext of the terminal hash value in the binding instruction according to the authorization code to obtain a first decryption result; calculating according to the authorization code, the verification data and the hardware wallet public key to obtain a device hash value;

the first judgment unit is used for judging whether the hash value of the equipment is equal to the first decryption result or not, if so, the verification is successful, the storage setting module is triggered, otherwise, the verification is failed, verification failure information is returned to the terminal, and the first judgment module is triggered;

the second authentication module comprising:

the computing unit is used for computing the ciphertext of the terminal hash value in the binding instruction according to the authorization code to obtain a first decryption result; calculating according to the authorization code, the verification data and the hardware wallet public key to obtain a device hash value;

and the second judgment unit is used for judging whether the hash value of the equipment is equal to the first decryption result or not, if so, the verification is successful, the judgment and storage module is triggered, otherwise, the verification fails, verification failure information is returned to the terminal, and the first judgment module is triggered.

21. The apparatus of claim 20, wherein the computing unit comprises:

the first calculation subunit is configured to perform hash operation on the authorization code to obtain a first hash result, perform hash operation on a preset constant to obtain a second hash result, and perform xor calculation on the first hash result and the second hash result to obtain an xor result;

a decryption negotiation subunit, configured to use the first 16 bytes of the xor result as an initial vector of encryption and decryption operations; performing key agreement by using the stored verification data and a hardware wallet public key according to a key agreement algorithm to obtain and store a device ciphertext, and taking the first 16 bytes of data of the device ciphertext as a first key;

the decryption calculation subunit is configured to decrypt, using the first key and the initial vector, a ciphertext of the terminal hash value in the binding instruction to obtain a first decryption result; and calculating according to the authorization code, the verification data and the hardware wallet public key to obtain the equipment hash value.

22. The apparatus according to claim 21, wherein the decryption computation subunit is configured to compute, according to the authorization code, the verification data, and the hardware wallet public key, a device hash value, and specifically: the decryption computation subunit is configured to sequentially splice the authorization code, the verification data, and the hardware wallet public key to obtain a spliced value, and perform hash operation on the spliced value to obtain an equipment hash value.

Technical Field

The invention relates to the field of information security, in particular to a method and a device for binding and authorizing a hardware wallet.

Background

The hardware wallet is a plug-and-play device which stores the private key of the digital asset in a chip separately and isolated from the internet. In the prior art, a hardware wallet adopts a pairing code and PIN code verification mode, the pairing code and PIN code of the hardware wallet need to be verified when a terminal is connected with the hardware wallet for the first time, and the pairing code and PIN code of the hardware wallet can be connected for use after both the pairing code and PIN code are successfully verified; when the hardware wallet is lost, once the PIN code and the pairing code are guessed by an illegal user, the hardware wallet is successfully connected to the terminal, and the illegal user can transfer the assets of a legal user, so that the property of the legal user has potential safety hazards.

Disclosure of Invention

The invention aims to overcome the defects of the prior art and provides a method and a device for binding and authorizing a hardware wallet.

The invention provides a method for binding and authorizing a hardware wallet, which comprises the following steps:

step S1: when the hardware wallet receives a command sent by the terminal, judging the type of the command, if the command is a command for inquiring the binding state, executing the step S2, if the command is a command for generating an authorization code, executing the step S5, and if the command is a binding command, executing the step S7;

step S2: the hardware wallet judges the value of the verification data existence flag stored inside, if the value is the first preset data, the binding object is set to be null, the authorization state is set to allow the generation of the authorization code, and step S4 is executed; if the second preset data is the second preset data, executing step S3;

step S3: the hardware wallet judges whether the verification data in the inquiry binding state instruction is consistent with the stored verification data, if so, the binding object is set as a terminal corresponding to the hardware wallet, and a step S4 is executed, otherwise, the binding object is set as other terminals, and a step S4 is executed;

step S4: the hardware wallet organizes the command response data according to the binding object and the saved hardware wallet certificate and returns the command response data to the terminal, and the step returns to step S1;

step S5: the hardware wallet judges whether the authorization state is the permission to generate the state code, if so, the step S6 is executed, otherwise, the error information is returned to the terminal, and the step S1 is returned;

step S6: the hardware wallet generates, caches and displays the authorization code, sets the authorization state as authorization code which cannot be regenerated, sets the hardware wallet state as unbound, returns success information to the terminal, and returns to step S1;

step S7: the hardware wallet judges whether the hardware wallet state is unbound, if so, the cached authorization code is obtained, and step S8 is executed, otherwise, the stored authorization code is obtained, and step S10 is executed;

step S8: the hardware wallet verifies the binding instruction by using the acquired authorization code, if the verification is successful, the step S9 is executed, if the verification is failed, verification failure information is returned to the terminal, and the step S1 is returned;

step S9: the hardware wallet stores the verification data and the cached authorization code in the binding instruction, sets the value of the verification data existence flag as second preset data, returns authorization success information to the terminal, and returns to the step S1;

step S10: the hardware wallet verifies the binding instruction by using the acquired authorization code, if the verification is successful, the step S11 is executed, if the verification is failed, verification failure information is returned to the terminal, and the step S1 is returned;

step S11: and the hardware wallet judges whether the currently connected terminal is the terminal corresponding to the hardware wallet according to the binding instruction, if so, returns authorization success information to the terminal, and returns to the step S1, otherwise, the hardware wallet stores the verification data in the binding instruction, sets the value of the verification data existence flag as second preset data, returns authorization success information to the terminal, and returns to the step S1.

Further, the steps S9 and S11 further include: the hardware wallet sets a binding state code of the hardware wallet and the terminal as a preset value;

the step S1 further includes: when the hardware wallet judges that the type of the received instruction sent by the terminal is a signature instruction, the hardware wallet judges whether the status code of the binding between the hardware wallet and the terminal is a preset value, if so, the signature operation is carried out according to the signature instruction, the step S1 is returned, otherwise, error information is returned to the terminal.

Further, step S2 is preceded by: the hardware wallet obtains the value of the validation data presence flag from a preset cache.

Further, the hardware wallet generating the authorization code comprises:

the hardware wallet generates a random number with a preset length and generates a retrieval code according to the random number and a preset character coding table; and sequentially splicing the values of the retrieval codes to form the authorization codes.

Further, step S7 is preceded by: and the hardware wallet judges whether the binding instruction is legal or not, if so, the step S7 is executed, otherwise, an error message is returned to the terminal, and the step S1 is returned.

Further, the hardware wallet determines whether the binding instruction is legal, specifically: and the hardware wallet judges whether the third byte data in the binding instruction is a first preset value or a second preset value and judges whether the fourth byte data is a third preset value, if so, the binding instruction is legal, otherwise, the binding instruction is illegal.

Further, the step S11 includes: and the hardware wallet judges whether the third byte data in the binding instruction is a second preset value, if so, authorization success information is returned to the terminal, the step is returned to S1, otherwise, the verification data in the binding instruction is saved, the value of the verification data existence mark is set as second preset data, authorization success information is returned to the terminal, and the step is returned to S1.

Further, the setting of the hardware wallet state as unbound specifically includes: the hardware wallet sets an authorization code mark as a preset value;

the step S7 includes: and the hardware wallet judges whether the authorization code mark is a preset value, if so, the cached authorization code is obtained, and the step S8 is executed, otherwise, the stored authorization code is obtained, and the step S10 is executed.

Further, the hardware wallet verifying the binding instruction using the obtained authorization code, 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 a first decryption result; calculating according to the authorization code, the verification data and the hardware wallet public key to obtain a device hash value;

step A2: and the hardware wallet judges whether the hash value of the equipment is equal to the first decryption result, if so, the verification is successful, and otherwise, the verification fails.

Further, the step a1 includes:

step b 1: the hardware wallet performs hash operation on the authorization code to obtain a first hash result, performs hash operation on a preset constant to obtain a second hash result, and performs exclusive-or calculation on the first hash result and the second hash result to obtain an exclusive-or result;

step b 2: the hardware wallet takes the first 16 bytes of the XOR result as an initial vector of encryption and decryption operation; performing key agreement by using the stored verification data and a hardware wallet public key according to a key agreement algorithm to obtain and store a device ciphertext, and taking the first 16 bytes of data of the device ciphertext as a first key;

step b 3: the hardware wallet decrypts a ciphertext of a terminal hash value in the binding instruction by using the first key and the initial vector to obtain a first decryption result; and calculating according to the authorization code, the verification data and the hardware wallet public key to obtain the equipment hash value.

Further, the calculating according to the authorization code, the verification data, and the hardware wallet public key to obtain the device hash value specifically includes: and sequentially splicing the authorization code, the verification data and the hardware wallet public key to obtain a spliced value, and performing hash operation on the spliced value to obtain an equipment hash value.

The invention also provides a device for binding and authorizing the hardware wallet, which comprises:

the first judgment module is used for judging the type of the instruction when the hardware wallet receives the instruction sent by the terminal, triggering the second judgment module if the instruction is a binding state inquiry instruction, triggering the third judgment module if the instruction is an authorization code generation instruction, and triggering the fourth judgment module if the instruction is a binding instruction;

the second judging module is used for judging and judging the value of the verification data existence mark stored inside, if the verification data existence mark is first preset data, the binding object is set to be null, the authorization state is set to be allowed to generate an authorization code, and the first returning module is triggered; if the first preset data is the second preset data, triggering a judgment setting module;

the judging and setting module is used for judging whether the verification data in the inquiry binding state instruction is consistent with the stored verification data, if so, the binding object is set as a terminal corresponding to the hardware wallet, and the first returning module is triggered, otherwise, the binding object is set as other terminals, and the first returning module is triggered;

the first returning module is used for organizing command response data according to the binding object and the stored hardware wallet certificate and returning the command response data to the terminal to trigger the first judging module;

the third judging module is used for judging whether the authorization state is a state code allowed to be generated or not, if so, the generating and setting module is triggered, otherwise, error information is returned to the terminal, and the first judging module is triggered;

the generation setting module is used for generating, caching and displaying the authorization code, setting the authorization state as an authorization code which can not be regenerated, setting the hardware wallet state as unbound, returning success information to the terminal, and triggering the first judgment module;

the fourth judging module is used for judging whether the hardware wallet state is unbound or not, if so, the cached authorization code is obtained, and the first verifying module is triggered, otherwise, the stored authorization code is obtained, and the second verifying module is triggered;

the first verification module is configured to verify the binding instruction by using the acquired authorization code, trigger the storage setting module if the verification is successful, and return verification failure information to the terminal if the verification is failed, so as to trigger the first judgment module;

the storage setting module is configured to store the verification data and the cached authorization code in the binding instruction, set a value of a verification data existence flag to be second predetermined data, return authorization success information to the terminal, and trigger the first determining module;

the second verification module is configured to verify the binding instruction by using the obtained authorization code, trigger the judgment and storage module if the verification is successful, and return verification failure information to the terminal if the verification is failed, and trigger the first judgment module;

and the judging and storing module is used for judging whether the currently connected terminal is the terminal corresponding to the hardware wallet according to the binding instruction, if so, returning authorization success information to the terminal to trigger the first judging module, otherwise, storing the verification data in the binding instruction, setting the value of a verification data existence mark as second preset data, returning authorization success information to the terminal, and triggering the first judging module.

Further, the saving setting module is also used for setting the binding state code of the hardware wallet and the terminal to a preset value;

the device also comprises a signature judging module, which is used for judging whether a state code bound by the hardware wallet and the terminal is a preset value or not when the first judging module judges that the type of the received instruction sent by the terminal is a signature instruction, if so, the signature judging module carries out signature operation according to the signature instruction and triggers the first judging module, otherwise, the first judging module is triggered by returning error information to the terminal.

Further, the apparatus further comprises: and the first acquisition module is used for acquiring the value of the verification data existence mark from the preset cache.

Further, the generating the setting module, configured to generate the authorization code, includes: the generation setting module is used for generating a random number with a preset length and generating a retrieval code according to the random number and a preset character coding table; and sequentially splicing the values of the retrieval codes to form the authorization codes.

Further, the device further comprises a fifth judging module, configured to, when the first judging module judges that the type of the instruction is a binding instruction, judge whether the binding instruction is legal, if so, trigger the fourth judging module, otherwise, return an error message to the terminal, and trigger the first judging module.

Further, the fifth judging module is specifically configured to, when the first judging module judges that the type of the instruction is the binding instruction, judge whether third byte data in the binding instruction is a first preset value or a second preset value, and judge whether fourth byte data is a third preset value, if yes, trigger the fourth judging module, otherwise, return an error message to the terminal, and trigger the first judging module.

Further, the judging and storing module is specifically configured to judge whether third byte data in the binding instruction is a second preset value, if so, return authorization success information to the terminal, otherwise, store the verification data in the binding instruction, set the value of the verification data existence flag to be second preset data, return authorization success information to the terminal, and trigger the first judging module.

Further, the generation setting module is configured to set the hardware wallet state as unbound, specifically: the generation setting module is used for setting the authorization code mark as a preset value;

the fourth judging module is specifically configured to judge whether the authorization code flag is a preset value, if so, obtain the cached authorization code, and trigger the first verifying module, and otherwise, obtain the stored authorization code, and trigger the second verifying module.

Further, the first authentication module includes:

the computing unit is used for computing the ciphertext of the terminal hash value in the binding instruction according to the authorization code to obtain a first decryption result; calculating according to the authorization code, the verification data and the hardware wallet public key to obtain a device hash value;

the first judgment unit is used for judging whether the hash value of the equipment is equal to the first decryption result or not, if so, the verification is successful, the storage setting module is triggered, otherwise, the verification is failed, verification failure information is returned to the terminal, and the first judgment module is triggered;

the second authentication module comprising:

the computing unit is used for computing the ciphertext of the terminal hash value in the binding instruction according to the authorization code to obtain a first decryption result; calculating according to the authorization code, the verification data and the hardware wallet public key to obtain a device hash value;

and the second judgment unit is used for judging whether the hash value of the equipment is equal to the first decryption result or not, if so, the verification is successful, the judgment and storage module is triggered, otherwise, the verification fails, verification failure information is returned to the terminal, and the first judgment module is triggered.

Further, the calculation unit includes:

the first calculation subunit is configured to perform hash operation on the authorization code to obtain a first hash result, perform hash operation on a preset constant to obtain a second hash result, and perform xor calculation on the first hash result and the second hash result to obtain an xor result;

a decryption negotiation subunit, configured to use the first 16 bytes of the xor result as an initial vector of encryption and decryption operations; performing key agreement by using the stored verification data and a hardware wallet public key according to a key agreement algorithm to obtain and store a device ciphertext, and taking the first 16 bytes of data of the device ciphertext as a first key;

the decryption calculation subunit is configured to decrypt, using the first key and the initial vector, a ciphertext of the terminal hash value in the binding instruction to obtain a first decryption result; and calculating according to the authorization code, the verification data and the hardware wallet public key to obtain the equipment hash value.

Further, the decryption calculation subunit is configured to calculate, according to the authorization code, the verification data, and the hardware wallet public key, to obtain the device hash value, and specifically: the decryption computation subunit is configured to sequentially splice the authorization code, the verification data, and the hardware wallet public key to obtain a spliced value, and perform hash operation on the spliced value to obtain an equipment hash value.

Compared with the prior art, the invention has the following advantages:

according to the technical scheme, the terminals and the hardware wallets are bound in a one-to-one correspondence mode, if the hardware wallets need to be connected with new terminals, whether the terminals are authorized to be connected with the hardware wallets or not is judged through the authorization codes, if the terminals are authorized, the new terminals are allowed to be connected with the hardware wallets, and safety of user assets is guaranteed when the hardware wallets are lost or unauthorized.

Drawings

Fig. 1 is a flowchart of a method for hardware wallet binding authorization according to an embodiment of the present invention;

fig. 2 and fig. 3 are flow charts of a method for hardware wallet binding authorization according to a second embodiment of the present invention;

fig. 4 is a block diagram of an apparatus for binding and authorizing a hardware wallet according to a third embodiment of the present invention.

Detailed Description

The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

22页详细技术资料下载
上一篇:一种医用注射器针头装配设备
下一篇:基于区块链的企业数据签名方法及装置

网友询问留言

已有0条留言

还没有人留言评论。精彩留言会获得点赞!

精彩留言,会给你点赞!