Hardware wallet offline operation method, system working method and hardware wallet device

Abstract

This invention discloses a method for offline operation of a hardware wallet, a system operating method, and a hardware wallet device, belonging to the field of hardware wallet technology. The method stores a lexical structure containing lexical values ​​and public-private key pairs in the hardware wallet, enabling lexical segmentation and merging operations in a trusted offline environment. During lexical operations, the hardware wallet constructs payload data within its security component, uses the corresponding private key to sign and generate authentication information, and records the authentication data in a lexical conversion operation log file. After the hardware wallet connects to the network, it can synchronize the complete lexical conversion operation authentication data to the backend system for verification. This invention solves the problem of hardware wallet redundancy in existing technologies through lexical segmentation and merging mechanisms, avoiding the accumulation of lexical data in offline environments; and utilizes an authentication mechanism to ensure the integrity and traceability of lexical conversion operations, thereby improving the user experience and security of offline digital currency operations.

Description

Technical Field

[0001] This invention relates to the field of hardware wallet technology, and in particular to a hardware wallet offline operation method, system operation method, and hardware wallet device. Background Technology

[0002] Since the advent of hardware wallet technology, digital currencies and related technologies have been widely applied and developed. Central Bank Digital Currencies (CBDCs) developed by central banks around the world are gradually changing the way traditional financial payment systems operate.

[0003] However, existing digital currency technologies have always relied on online network environments for transaction verification and settlement. While online transactions offer advantages such as real-time performance and high security, in scenarios with insufficient network coverage, such as remote areas with weak communication infrastructure, network outages during disasters, and special environments like underground transportation, the online transaction function of digital currencies will be severely limited, failing to meet users' basic payment needs.

[0004] How to complete reliable offline payments has always been a pain point and challenge in the promotion and application of digital currency technology. The People's Bank of China's Digital Currency Research Institute proposed an offline payment method based on "coin strings." This method represents digital currency as specific coin strings, and users complete transactions by exchanging these strings. However, this technical solution has a significant technical flaw: coin strings cannot be merged during transactions. Specifically, after multiple offline transactions, a large number of coin strings of different denominations accumulate in the user's wallet. Because these strings cannot be merged, they continuously occupy wallet storage space, leading to an ever-increasing number of strings in the wallet. This not only affects the user experience but may also cause the wallet to run out of storage space, affecting subsequent transactions.

[0005] Furthermore, existing offline payment solutions have shortcomings in transaction verification. When the device reconnects to the internet, the backend system struggles to obtain complete offline transaction authentication, resulting in a lack of effective assurance regarding transaction integrity and traceability.

[0006] Therefore, there is an urgent need to provide a new offline operation method for hardware wallets to solve the technical problems in existing technologies, such as the inability to merge coin strings in digital currency wallets, leading to wallet redundancy and incomplete transaction authentication chains. Summary of the Invention

[0007] In the technical architecture of the digital yuan, the "currency string" proposed by the People's Bank of China's Digital Currency Research Institute is essentially a unique structured data unit that is signed by an encrypted algorithm. It achieves accurate value expression and secure transfer through specific encoding and verification mechanisms. From the perspective of underlying data processing logic, this idea of ​​a computable digital string is also applicable to the field of text information processing.

[0008] This application proposes the concept of "word element", which is based on the idea of ​​structurally encapsulating data units using "coin string" to form standardized digital strings. In this invention, the "word element" and "coin string" have the same circulation value and are both basic data units that can be computed.

[0009] The purpose of this invention is to provide a hardware wallet offline operation method, system operation method, and hardware wallet device to solve the problems of hardware wallet redundancy and incomplete transaction authentication chain in the prior art, realize word segmentation and merging operations in a trusted offline environment, and provide a complete transaction authentication chain for the background when connected to the network.

[0010] To achieve the above objectives, on the one hand, the present invention provides an offline operating system for a hardware wallet, including a first hardware wallet, a second hardware wallet, and a host computer, which performs the following steps: Step 1: The first hardware wallet receives a first instruction from the host computer for a segmented word conversion operation and executes step 2-1; the second hardware wallet receives a first instruction from the host computer for a merged word conversion operation and executes step 2-1'. Step 2-1: The first hardware wallet obtains the converted lexical value from the first instruction of the lexical conversion operation, determines whether the data stored in itself can be used to execute the first instruction of the lexical conversion operation, and if so, generates a first application file locator and returns the first application file locator to the host computer, and executes step 2-2; otherwise, it reports an error. Step 2-1': The second hardware wallet obtains the transformed token value from the first instruction of the token transformation operation, determines whether its stored data can be used to execute the first instruction of the token transformation operation, and if so, generates a public-private key pair of transformed tokens and a second application file locator, and returns the second application file locator to the host computer. The host computer reads the transformed token public key through the second application file locator, uses the transformed token public key to construct the second instruction of the token transformation operation and sends it to the first hardware wallet, and executes step 2-2; otherwise, an error is reported. Step 2-2: The first hardware wallet receives the second instruction for lexical conversion operation sent by the host computer, constructs the first payload data, and signs the hash value of the first payload data using the first original lexical private key to generate the first payload data signature value. Steps 2-3: The first hardware wallet deletes the first original word element; Steps 2-4: The first hardware wallet returns the first payload data and the first payload data signature value to the host computer. The host computer uses the first payload data and the first payload data signature value to construct a third instruction for lexical conversion operation and sends it to the second hardware wallet. Steps 2-5: The second hardware wallet receives the third instruction of the lexical conversion operation, obtains the first payload data and the first payload data signature value from the third instruction of the lexical conversion operation, and verifies the first payload data. If the verification is successful, proceed to step 2-6; otherwise, report an error. Step 2-6: The second hardware wallet verifies the signature value of the first payload data. If the verification passes, proceed to step 2-7; otherwise, report an error. Steps 2-7: The second hardware wallet constructs the second payload data and calculates the hash value. It uses the second original token private key to perform a signature calculation on the hash value of the second payload data to generate a first signature value of the second payload data. It uses the transformed token private key to perform a signature calculation on the hash value of the second payload data to generate a second signature value of the second payload data. It uses the first signature value of the second payload data and the second signature value of the second payload data to construct a second payload data signature value. Steps 2-8: The second hardware wallet deletes the converted tokens and the second original tokens; Steps 2-9: The second hardware wallet returns the second payload data and the second payload data signature value to the host computer; The method further includes: when the first hardware wallet receives the first instruction of the word conversion operation or the second instruction of the word conversion operation, constructing a first new word; When the second hardware wallet receives the first instruction or the third instruction of the word conversion operation, it constructs a second new word.

[0011] The first new lexical element includes a first new lexical element value and a first new lexical element public / private key pair, wherein the first new lexical element value is the difference between the first original lexical element value and the transformed lexical element value; The second new lexical element includes a second new lexical element value and a second new lexical element public / private key pair. The second new lexical element value is the sum of the second original lexical element value and the transformed lexical element value.

[0012] The first application file locator stores address information related to the lexical transformation operation of the first hardware wallet. The data related to the lexical transformation operation of the first hardware wallet includes: the ID of the first hardware wallet, the original lexical value of the first hardware wallet, the original lexical public key of the first hardware wallet, and the lexical transformation operation log of the first hardware wallet.

[0013] The host computer, based on the first application file locator, reads the ID of the first hardware wallet, the original token value of the first hardware wallet, the original token public key of the first hardware wallet, and the token conversion operation log of the first hardware wallet from the first hardware wallet through a read record instruction.

[0014] The second application file locator stores address information related to the lexical transformation operation of the second hardware wallet. The lexical transformation operation related data includes: the ID of the second hardware wallet, the public key of the transformed lexical in the public-private key pair, the original lexical value of the second hardware wallet, the original lexical public key of the second hardware wallet, and the lexical transformation operation log of the second hardware wallet.

[0015] The host computer, based on the second application file locator, reads the ID of the second hardware wallet, the public key of the transformed token in the public-private key pair, the original token value of the second hardware wallet, the original token public key of the second hardware wallet, and the token transformation operation log of the second hardware wallet from the second hardware wallet through a read record instruction.

[0016] Step 2-2 specifically includes: Step 2-2-1: When the first hardware wallet receives the second instruction for word conversion operation sent by the host computer, it obtains the public key of the converted word through the second instruction for word conversion operation. Step 2-2-2: The first hardware wallet constructs first payload data including the first original lexical value, the transformed lexical value, the first new lexical value, the first original lexical public key, the transformed lexical public key, and the first new lexical public key; Step 2-2-3: The first hardware wallet performs a hash calculation on the first payload data to generate a hash value for the first payload data; Step 2-2-4: The first hardware wallet uses the first original token private key to perform a signature calculation on the hash value of the first payload data to generate the first payload data signature value; Step 2-2-5: The first hardware wallet writes the first payload data and the first payload data signature value into the lexical conversion operation log of the first hardware wallet.

[0017] Before steps 2-5, the host computer further includes: writing the lexical conversion operation log of the first hardware wallet into the cache area of ​​the second hardware wallet by appending a proof record instruction, and the second hardware wallet returns a save response to the host computer.

[0018] Steps 2-5 specifically include: When the second hardware wallet receives the third instruction for lexical conversion operation sent by the host computer, it obtains the first payload data and the first payload data signature value from the third instruction for lexical conversion operation, and verifies whether the public key of the converted lexical in the first payload data is consistent with the public key of the converted lexical generated by the second hardware wallet; if they are consistent, steps 2-6 are executed; otherwise, an error is reported, and the lexical conversion operation log of the first hardware wallet stored in the cache area of ​​the second hardware wallet is deleted. Steps 2-6 specifically include: The second hardware wallet uses the first original token public key in the first payload data to verify the signature value of the first payload data. If the verification is successful, steps 2-7 are executed; otherwise, an error is reported, and the token conversion operation log of the first hardware wallet stored in the cache of the second hardware wallet is deleted. Steps 2-7 specifically include: The second hardware wallet constructs second payload data comprising a second original lexical value, the transformed lexical value, a second new lexical value, a second original lexical public key, a second new lexical public key, and the transformed lexical public key. A hash algorithm is used to calculate a hash value for the second payload data. The hash value of the second payload data is signed using the second original lexical private key to generate a first signature value for the second payload data. The hash value of the second payload data is then signed using the transformed lexical private key to generate a second signature value for the second payload data. Finally, the first and second signature values ​​of the second payload data are used to construct a second payload data signature value.

[0019] Steps 2-7 further include: writing the first payload data, the first payload data signature value, the lexical conversion operation log of the first hardware wallet, the second payload data, and the second payload data signature value into the lexical conversion operation log of the second hardware wallet.

[0020] Steps 2-7 are followed by: after the host computer and / or the second hardware wallet are connected to the network, synchronizing the first payload data, the first payload data signature value, the word conversion operation log of the first hardware wallet, the second payload data, and the second payload data signature value to the hardware wallet backend server.

[0021] Steps 2-7 are followed by the following: the hardware wallet backend server writes the first payload data, the first payload data signature value, the first hardware wallet lexical conversion operation log, the second payload data, and the second payload data signature value into the authentication data storage area. The authentication data includes a lexical conversion value field, a lexical conversion operation type field, a lexical conversion operation log field, a payload data field, and a payload data signature value field.

[0022] The host computer is a smart terminal device including mobile phones and POS machines, and the hardware wallet is a smart card or an application module unit in the host computer.

[0023] The hardware wallet communicates with the host computer via contact or contactless methods.

[0024] On the other hand, the present invention also provides an offline operation method for a hardware wallet, wherein the hardware wallet stores original tokens, and the tokens include token values ​​and token public-private key pairs. The method includes the following steps: Step 101: The hardware wallet receives instructions from the host computer; Step 102: The hardware wallet determines the instruction type. When the instruction is a first instruction for lexical conversion operation, execute step 103-1. When the instruction is a second instruction for lexical conversion operation, execute step 103-2. When the instruction is a third instruction for lexical conversion operation, execute step 103-3. When the instruction is an instruction to append a proof record, execute step 103-4. When the instruction is an instruction to read a record, execute step 103-5. Step 103-1: The hardware wallet determines the operation type. If it is a splitting operation, then step 103-1-1 is executed; if it is a merging operation, then step 103-1-1' is executed. Step 103-1-1: The hardware wallet obtains the converted word value and determines whether the segmentation operation can be performed. If so, proceed to step 103-1-2; otherwise, return an error response to the host computer. Step 103-1-2: The hardware wallet generates an application file locator and returns the application file locator to the host computer; Step 103-1-1': The hardware wallet obtains the converted word value and determines whether the merging operation can be performed. If so, step 103-1-2' is executed; otherwise, an error response is returned to the host computer. Step 103-1-2': The hardware wallet generates a public-private key pair of conversion tokens and an application file locator, and returns the application file locator to the host computer; Step 103-2: The hardware wallet constructs payload data and calculates a hash value, signs the hash value of the payload data using the original token private key, and generates a payload data signature value; deletes the saved original tokens, and returns the payload data and the payload data signature value to the host computer. Step 103-3: The hardware wallet obtains the payload data and payload data signature value through the third operation instruction, and verifies whether the payload data is valid. If it is, then step 103-3-1 is executed; otherwise, an error response is returned to the host computer. Step 103-3-1: The hardware wallet verifies whether the payload data signature value is valid. If it is, proceed to step 103-3-2; otherwise, return an error response to the host computer. Step 103-3-2: The hardware wallet constructs its own payload data and calculates the first signature value and the second signature value of its own payload data, and uses the first signature value and the second signature value of its own payload data to construct the signature value of its own payload data; Step 103-3-3: The hardware wallet deletes the original tokens stored therein and returns its own payload data and the signature value of the payload data to the host computer. Step 103-4: Obtain the operation log from the hardware wallet acquisition instruction, store the operation log in the cache area, and return a storage response to the host computer; Step 103-5: The hardware wallet returns relevant data on hardware wallet lexical conversion operation to the host computer.

[0025] The present invention also provides a hardware wallet device for performing the aforementioned method, the hardware wallet device comprising: The processor unit is used to construct payload data and calculate new lexical values; A security component, connected to the processor unit, is used to generate and store token public-private key pairs, calculate the hash value of payload data, generate payload data signature value, and verify payload data signature value. A memory, connected to the processor unit, is used to store data related to hardware wallet lexical conversion operations; A communication interface, connected to the processor unit, is used for data communication with a host computer.

[0026] The security component includes a secure storage area for storing the public-private key pair of the term; The memory includes a designated file area for storing lexical conversion operation log files, which are addressed using short file identifiers.

[0027] The security component is also used to delete the original token private key from the secure storage area after calculating the payload data signature value.

[0028] The memory also includes a cache area for caching word conversion operation log data from the host computer.

[0029] The communication interface supports contact communication and / or contactless communication.

[0030] The hardware wallet device also includes: Application file locator generation unit, used to generate application file locators; The application file locator stores address information of data related to hardware wallet lexical conversion operations.

[0031] The hardware wallet device also includes: A lexical conversion operation counter is used to record the number of lexical conversions. The lexical conversion limit parameter unit is used to set the upper limit of the number of lexical conversions; Before performing the word conversion operation, the processor unit verifies the legality of the word conversion operation based on the maximum number of word conversion operations in the offline environment. When the word conversion operation counter reaches the maximum number of word conversion operations, the processor unit prompts the network to connect.

[0032] The hardware wallet device also includes: A lexical value counter is used to record the lexical values ​​of lexical transformation operations; The lexical conversion operation lexical value limit parameter unit is used to set the maximum converted lexical value for a single lexical conversion operation and the cumulative converted lexical value for the lexical conversion operation; Before performing the word conversion operation, the processor unit verifies the legality of the word conversion operation based on the maximum converted word value of a single conversion operation in the offline environment and the cumulative converted word value of the word conversion operation.

[0033] The present invention also provides a computer system, including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the steps of the aforementioned method.

[0034] The hardware wallet offline operation method, system operation method, and hardware wallet device provided by this invention have the following beneficial effects: First, by using a lexical structure containing lexical values ​​and public-private key pairs, lexical operations are performed within the secure component of the hardware wallet, enabling trusted processing of lexical data in an offline environment. The private key for each lexical element is always stored within the secure component and is not exposed externally, ensuring the security of lexical operations.

[0035] Secondly, through token segmentation and token merging operations, users can flexibly manage tokens in an offline environment. When a user makes a payment using the hardware wallet, the hardware wallet segments the current token into transaction tokens and remaining tokens based on the transaction amount, facilitating user payment. When a user receives a payment using the hardware wallet, the hardware wallet merges the received tokens with the existing tokens in the wallet, avoiding redundancy issues caused by the continuous accumulation of tokens in the wallet. After the signature operation is completed, the original token private key is deleted, effectively saving storage space in the hardware wallet.

[0036] Furthermore, by generating an authentication chain containing the operational payload and cryptographic signature during lexical operations and recording the authentication in the lexical transformation operation log file, the integrity and traceability of lexical transactions are ensured. When connected to the internet, the hardware wallet can provide the backend system with the complete lexical transaction authentication chain, enabling the backend system to verify the legitimacy of all offline transactions.

[0037] Meanwhile, the technical solution of this invention ensures the cryptographic security of token operation authentication by adopting a digital signature algorithm; the application of the dual signature mechanism in token merging operation ensures that both input tokens authorize the legality of the merging operation, thus guaranteeing the security of the operation. Attached Figure Description

[0038] Figure 1 This is an overall flowchart of the hardware wallet offline operation and data synchronization after connecting to the network, provided in Embodiment 1 of the present invention.

[0039] Figure 2 This is a system flowchart of a hardware wallet performing offline operations provided in Embodiment 2 of the present invention.

[0040] Figure 3 This is a firmware flowchart for performing offline operations on a hardware wallet, provided in Embodiment 3 of the present invention.

[0041] Figure 4 This is a flowchart of the hardware wallet performing word segmentation operation provided in Embodiment 4 of the present invention.

[0042] Figure 5 This is a flowchart of the hardware wallet performing lexical merging operations provided in Embodiment 5 of the present invention.

[0043] Figure 6 This is a structural block diagram of the hardware wallet device provided in Embodiment Six of the present invention. Detailed Implementation

[0044] The technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention. Example 1

[0045] See Figure 1 The diagram illustrates the overall flowchart of offline operation and data synchronization of the hardware wallet after connecting to the network, as provided in Embodiment 1 of the present invention.

[0046] In this embodiment, the lexical transformation in the hardware wallet is a specific application of its transaction operation. This transaction operation is specifically manifested as the interaction between the payer's and recipient's hardware wallets through a terminal. Before describing this method, the lexical structure needs to be defined; In this embodiment of the invention, a term is an atomic value unit in a digital currency system. Each term consists of the following three fields: Term value: Multi-byte data representing the denomination of a term. In this embodiment, the term value is an unsigned 32-bit integer encoded in big-endian. For example, 0x000003E8 represents 1000 currency units.

[0047] Public key: Multi-byte data, using the NISTP-256 elliptic curve SEC1 compression format. In this embodiment, it includes a 1-byte prefix (02 or 03) and a 32-byte X-coordinate. The public key is an externally visible token identifier.

[0048] Private key: A multi-byte data item stored within the security component. It serves as a credential for controlling the token; in this embodiment, it is specifically 32 bytes. The private key remains in a secure, isolated area of ​​the security component throughout the token's lifecycle and is never exposed or transmitted externally.

[0049] Therefore, in this embodiment, the externally visible storage space for the lexical unit is 37 bytes (4-byte lexical value + 33-byte public key), while the complete lexical unit structure requires an additional 32 bytes of private key storage space.

[0050] like Figure 1 As shown, the method includes the following steps: S101: The hardware wallet receives token transaction requests in an offline environment; The hardware wallet receives token transaction requests from external terminals via a communication interface. Token transaction requests include data such as transaction type identifier, transaction amount, and transaction object information.

[0051] S102: Determine the type of token transaction request; Based on the transaction type identifier in the token transaction request, the type of token operation to be performed is determined. This embodiment of the invention supports two types of token operations: segmentation operation and merging operation. S103 (S103'): Perform the corresponding lexical operations and generate authentication data; Based on the determined transaction request type, the corresponding lexical operations are performed within the hardware wallet's security component, and authentication data is generated. The execution process is as follows: The original token values ​​are retained, and a new key pair (containing a new public key and a new private key) is generated within the security component of the hardware wallet.

[0052] Construct the load data. Transform the load data into a fixed field width format, with fields concatenated sequentially without length prefixes or separators.

[0053] The SHA256 hash value of the transformed payload data is signed using the private key of the original tokens to generate signature data.

[0054] The private key of the original token is erased from the secure storage area, completing the key replacement.

[0055] S104: The hardware wallet connects to the network and sends authentication data to the backend system. The backend system verifies the authentication information, updates the ledger status based on the verification result, and returns a synchronization confirmation to the hardware wallet.

[0056] When the hardware wallet regains internet connectivity, a network synchronization process is executed. Network synchronization includes the following steps: Establish a secure communication connection between the hardware wallet and the backend system.

[0057] All transaction records in the token conversion operation log file are arranged in chronological order to form complete authentication data.

[0058] The authentication information is sent to the backend system. The authentication data includes complete information and cryptographic authentication for each transaction.

[0059] The backend system verifies the received authentication information. The verification process includes: Extract payload data from each transaction record; Verify the number and validity of signatures based on the operation type; Verify whether the conservation constraints are satisfied; To verify the validity of the signature, the corresponding public key is used to verify the correctness of the signature.

[0060] The backend system updates the ledger status based on the verification results and sends a synchronization confirmation back to the hardware wallet.

[0061] If all lexical values ​​in the hardware wallet have been reduced to zero, the hardware wallet needs to perform a lexical transformation operation to generate new lexical values. Example 2

[0062] join Figure 2 This document illustrates a system flowchart of the hardware wallet performing offline operations provided in this embodiment, which shows the complete process of the hardware wallet offline operating system implementing payment and receipt in an offline environment.

[0063] In this embodiment, the term "digital currency" (abbreviated as "digital currency") is composed of: digital currency denomination and public / private key pair corresponding to the digital currency denomination.

[0064] Token segmentation occurs when the hardware wallet performs a payment operation, while token merging occurs when the hardware wallet performs a receiving operation. The key pair of transaction tokens is generated in the recipient's wallet (hereinafter referred to as the recipient) and the public key in the key pair of transaction tokens is sent to the payer's wallet (hereinafter referred to as the payer) through the bridge device for the payer to use in constructing payload data.

[0065] When the payer performs a split operation, it generates the remaining token values ​​after splitting and the corresponding public-private key pairs; when the payee performs a merge operation, it generates the merged token values ​​and the corresponding public-private key pairs.

[0066] When the payee performs a signature operation, it needs to complete two signature operations using the payee's original token private key and the transaction token private key.

[0067] In an offline environment, the payer will send the payload data signature value generated during the splitting operation to the payee for verification. After connecting to the network, the payee will synchronize the payload data signature value and token conversion operation log generated during the merging operation to the backend, and the backend will verify the signature.

[0068] The payload data in the token conversion operation log contains the public keys of the token source address and destination address, which the backend can use to assemble a complete transaction chain. Each token transfer is certified by signing with the private key of the source address.

[0069] In this embodiment, the host computer is a bridge device used to realize data communication during the payment and receipt process. It can be a smart terminal device such as a mobile phone or POS machine, and the hardware wallet can be a smart card, a mobile phone SIM card, or an application module placed in the terminal device.

[0070] In the application scenario of this embodiment, hardware wallet A is an application module of a hardware wallet placed in the user's mobile phone, and hardware wallet B is a hardware wallet held by the payee. The user goes to an underground shopping mall without network to make a purchase with a transaction amount of 40 yuan. The user's mobile phone communicates with hardware wallet B via NFC.

[0071] Hardware wallet A contains digital currency with a face value of 100 yuan and the corresponding key pair {PK100, SK100}. Hardware wallet B contains digital currency with a face value of 30 yuan and the corresponding key pair {PK30, SK30}.

[0072] Step 201: After receiving the transaction instruction, the bridge device sends GPO instructions to hardware wallet A and hardware wallet B respectively. Hardware wallet A sets the operation type identifier value to "split operation type identifier value" and hardware wallet B sets the operation type identifier value to "merge operation type identifier value". In this embodiment, the transaction instruction is an instruction from the user via the input device (keyboard, microphone, etc.) of the bridge device to transfer digital currency with a face value of 40 yuan from hardware wallet A to hardware wallet B.

[0073] Step 202: Determine if the conditions are suitable for executing the GPO command. If yes, return AFL (Application File Locator) to the bridge device; proceed to step 203; otherwise, report an error. In this embodiment, the GPO instruction sent to hardware wallet A is a transaction initialization instruction, which includes: transaction amount, transaction type, digital currency, etc.

[0074] When hardware wallet A receives the GPO instruction from the bridge device, it determines whether its own conditions are suitable for executing the GPO instruction. Specifically, it checks whether its consecutive offline transaction count, single transaction amount, and cumulative consecutive offline transaction amount exceed the limits, whether the stored original currency denomination is sufficient to support the current payment operation, and whether it supports payment operations in the current transaction currency, etc.

[0075] Step 203: The bridge device reads the transaction-related data of hardware wallet A according to the Read Record instruction of AFL, and then executes step 204; In this embodiment, the transaction-related data of hardware wallet A includes: the ID of hardware wallet A, the current digital currency denomination, the public key PK100 corresponding to the current digital currency denomination, and the digital currency transaction log of hardware wallet A.

[0076] Accordingly, Step 202': Determine if the conditions allow the execution of the GPO command. If yes, generate a key pair {PK40, SK40} corresponding to the digital currency of the transaction amount, place PK40 in the specified record, return AFL to the bridge device, and execute step 203'. Otherwise, report an error. In this embodiment, the GPO instruction sent to hardware wallet B is a transaction initialization instruction, which includes: transaction amount, transaction type, digital currency, etc.

[0077] When hardware wallet B receives the GPO instruction from the bridge device, it determines whether its own conditions are suitable for executing the GPO instruction. Specifically, it checks whether its consecutive offline transaction count, single transaction amount, and cumulative consecutive offline transaction amount exceed the limits, and whether it supports receiving payments for the current transaction currency.

[0078] Step 203': The bridge device reads the transaction-related data of hardware wallet B according to the AFL through the Read Record instruction, and executes step 204; In this embodiment, the transaction-related data of hardware wallet B includes: the ID of hardware wallet B, the public key PK40 in the key pair corresponding to the transaction denomination, the current digital currency denomination, the public key PK30 corresponding to the current digital currency denomination, and the digital currency transaction log of hardware wallet B, etc.

[0079] Step 204: The bridge device writes the digital currency transaction logs read from hardware wallet A into the cache area of ​​hardware wallet B through the Append Record instruction, and sends the GAC instruction to hardware wallet A based on the public key PK40 in the key pair corresponding to the transaction amount read from hardware wallet B. Step 205: After receiving the GAC instruction from the bridge device, hardware wallet A obtains PK40 and performs the following operations: Step 205-1: Calculate the remaining digital currency denominations and generate key pairs {PK60, SK60} corresponding to the remaining denominations; Step 205-2: Perform the segmentation operation using {PK100, SK100}, PK40, and PK60, specifically including: Construct the first PAYLOAD data, first PAYLOAD data = {100, 60, 40, PK100, PK60, PK40}; Use SK100 to sign the hash value of the first PAYLOAD data to generate the first PAYLOAD data signature value; Step 205-3: Record the split operation type identifier value, the first PAYLOAD data, and the first PAYLOAD data signature value into the digital currency transaction log of hardware wallet A; Step 206: Hardware wallet A destroys the digital currency with a face value of 100 yuan and the corresponding key pair {PK100, SK100} stored within it. At this time, hardware wallet A contains digital currency with a face value of 60 yuan and its corresponding key pair {PK60, SK60}.

[0080] Step 207: Hardware wallet A returns the response data of the GAC instruction to the bridge device by assembling the first PAYLOAD data generated by the splitting operation and the signature value of the first PAYLOAD data. Step 208: The bridge device uses the first PAYLOAD data returned by hardware wallet A and the signature value of the first PAYLOAD data to construct a GAC ​​instruction and send it to hardware wallet B; Step 209: After receiving the GAC instruction from the bridge device, hardware wallet B performs the following operations: Step 209-1: Check if the public key in the key pair corresponding to the transaction amount in the first PAYLOAD data is consistent with the PK40 generated in step 202'; if they are consistent, proceed to 209-2; otherwise, report an error and delete the digital currency transaction logs of hardware wallet A stored in the cache. Step 209-2: Use PK100 in the first PAYLOAD data to verify the signature value of the first PAYLOAD data and determine whether the verification is successful. If it is, proceed to step 209-3; otherwise, report an error and delete the digital currency transaction log of hardware wallet A stored in the cache. Step 209-3: Save the first PAYLOAD data, the signature value of the first PAYLOAD data, and the digital currency transaction log of hardware wallet A stored in the cache area of ​​hardware wallet B to the digital currency transaction log of hardware wallet B. Step 209-4: Hardware wallet B calculates the merged digital currency denomination, generates a key pair {PK70, SK70} corresponding to the merged digital currency denomination, and uses it to perform the merge operation. It constructs the second PAYLOAD data and the signature value of the second PAYLOAD data, and records the merge operation type identifier value, the second PAYLOAD data, and the signature value of the second PAYLOAD data in the digital currency transaction log of hardware wallet B. In this embodiment, constructing the second PAYLOAD data and its signature value specifically includes: Step 209-4-1: Hardware wallet B constructs the second PAYLOAD data, where the second PAYLOAD data = {70, 40, 30, PK70, PK40, PK30}; Step 209-4-2: Calculate the hash value of the second PAYLOAD data; Step 209-4-3: Use the private key SK40 from the key pair corresponding to the transaction amount generated in step 202' to sign the hash value of the second PAYLOAD data, and generate the first signature value; Step 209-4-4: Use the SK30 stored within itself to sign the hash value of the second PAYLOAD data to generate a second signature; Step 209-4-5: Construct the second PAYLOAD data signature value using the first signature value and the second signature value; Step 210: Hardware wallet B destroys digital currency with a face value of 40 yuan and the corresponding key pair {PK40, SK40}, and digital currency with a face value of 30 yuan and the corresponding key pair {PK30, SK30}. At this time, hardware wallet B contains digital currency with a face value of 70 yuan and the corresponding key pair {PK70, SK70}. Step 211: Hardware wallet B returns the response data of the GAC instruction composed of the second PAYLOAD data generated after the merge operation and the second PAYLOAD data signature value to the bridge device; In this embodiment, after connecting to the network, the bridge device synchronizes the digital currency transaction logs, first PAYLOAD data, first PAYLOAD data signature value, second PAYLOAD data, and second PAYLOAD data signature value of the hardware wallet A to the backend server.

[0081] In this embodiment, both hardware wallet A and hardware wallet B can synchronize the digital currency transaction logs from when the network is offline to the backend server system after connecting to the network.

[0082] With the technical solution of this embodiment, since both the bridge device and hardware wallet B store the digital currency transaction logs of hardware wallet A, the integrity of the transaction chain can be guaranteed during synchronization, regardless of which device can connect to the backend.

[0083] Once hardware wallet A or hardware wallet B is connected to the network, it automatically executes the network synchronization process, assembling all transaction authentications (including splitting and merging operations) in the digital currency transaction log file into complete authentication data in chronological order, and sending it to the backend server system for verification.

[0084] The backend server system verifies the integrity and correctness of the authentication data, including verifying signature validity, checking conservation constraints, and confirming transaction order. Once verification is successful, the backend system updates the user's hardware wallet account status and completes network synchronization.

[0085] If a user's hardware wallet's offline transaction counter reaches a preset limit, the hardware wallet will verify the user's identity and confirm authorization for online synchronization before synchronizing online.

[0086] In summary, this invention enables the splitting and merging of digital currencies in a trusted offline environment through a hardware wallet offline operation method. By implementing a digital currency splitting and merging mechanism, it effectively solves the technical problem of wallet redundancy caused by the inability to merge digital currencies in existing technologies, thus improving the user experience of offline digital currency transactions. A complete authentication chain mechanism ensures the integrity and traceability of offline transactions, enhancing the security of offline digital currency transactions. Example 3

[0087] See Figure 3 This illustrates the firmware process for the hardware wallet side to perform transaction operations in an offline environment in this embodiment.

[0088] In this embodiment, the term "digital currency" refers to digital currency, which consists of: the face value of the digital currency and the public / private key pair of the digital currency.

[0089] Token segmentation occurs when a hardware wallet performs a digital currency (referred to as "digital currency") payment operation.

[0090] Metaword merging occurs when a hardware wallet performs a digital currency (referred to as "digital currency") payment transaction.

[0091] Each hardware wallet can perform both offline payment and offline receipt operations. The key pair of the transaction digital currency is generated in the receiving hardware wallet, and the public key in the transaction digital currency key pair is sent to the payment hardware wallet through the bridge device for the payment hardware wallet to use in building payload data.

[0092] The bridge device is a host computer used to realize data communication in digital currency transaction operations. In this embodiment, the bridge device is a smart POS machine, the payment hardware wallet is an application module in the smart POS machine, and the receiving hardware wallet is a hardware wallet card held by the user.

[0093] The hardware wallet card communicates with the POS machine containing the payment hardware wallet via NFC.

[0094] Preferably, the executable instructions of the hardware wallet in this embodiment include multiple application instructions, such as hardware wallet application instructions, VISA application instructions, PBOC application instructions, and MasterCard application instructions.

[0095] The specific execution process is as follows: Step 301: The hardware wallet receives instructions from the bridge device; Step 302: The hardware wallet determines the type of the received instruction. When a transaction initialization instruction is received, step 303-1 is executed. When a first transaction instruction is received, step 303-2 is executed. When a second transaction instruction is received, step 303-3 is executed. When an instruction to append proof records is received, step 303-4 is executed. When a read record instruction is received, step 303-5 is executed. Step 303-1: The hardware wallet determines the transaction operation type. If it is a payment operation, proceed to step 303-1-1; if it is a receipt operation, proceed to step 303-1-1'. Step 303-1-1: The hardware wallet obtains the transaction amount in cryptocurrency and determines whether the payment operation can be performed. If so, proceed to step 303-1-2; otherwise, return an error response to the bridge device. In this embodiment, the hardware wallet determines whether a payment operation can be performed by checking its own consecutive offline transaction count, the face value of a single transaction, whether the face value of the cumulative consecutive offline transaction exceeds the limit, and whether it supports the currency for this transaction.

[0096] Step 303-1-1': The hardware wallet obtains the transaction data denomination and determines whether the payment collection operation can be performed. If so, proceed to step 303-1-2'; otherwise, return an error response to the host computer. In this embodiment, the hardware wallet determines whether a payment receiving operation can be performed by checking: its number of consecutive offline transactions, the face value of a single transaction, whether the cumulative face value of consecutive offline transactions exceeds the limit, and whether it supports the currency for this transaction.

[0097] Step 303-1-2: The hardware wallet constructs the data structure of the remaining digital currency, generates a transaction initialization command response, and returns the transaction initialization command response to the bridge device, then returns to step 301; In this embodiment, the payment hardware wallet calculates the remaining digital currency denomination based on the transaction digital currency denomination and generates a public-private key pair corresponding to the remaining digital currency. The remaining digital currency denomination and the corresponding public-private key pair are used to construct the data structure of the remaining digital currency. The transaction initialization instruction response of the payment wallet includes an application file locator, which records the storage address of data related to the payment hardware wallet transaction.

[0098] Step 303-1-2': The hardware wallet generates the public key of the digital currency for this transaction, constructs the data structure for merging digital currencies, generates a transaction initialization command response, and returns the transaction initialization command response to the bridge device, then returns to step 301; In this embodiment, the receiving hardware wallet calculates the merged digital currency denomination based on the transaction digital currency denomination, and generates the public-private key pair corresponding to the merged digital currency and the public key of the transaction digital currency. The data structure of the merged digital currency is constructed using the merged digital currency denomination and the public-private key pair corresponding to the merged digital currency. The transaction initialization instruction response of the receiving wallet includes an application file locator, which records the storage address of the data related to the transaction of the receiving hardware wallet.

[0099] Step 303-2: The hardware wallet constructs payload data and calculates the hash value. It uses the private key of the original digital currency to sign the hash value of the payload data, generates the payload data signature value, and returns to step 301. In this embodiment, the first transaction instruction is an instruction sent by the bridge device to the hardware wallet that performs the payment operation in the current digital currency transaction operation. The hardware wallet obtains the transaction digital currency public key in the current digital currency transaction operation from the first transaction instruction. The payload data constructed by the hardware wallet that receives the first transaction instruction includes: the original digital currency denomination in the payment hardware wallet, the transaction digital currency denomination, the remaining digital currency denomination, the original digital currency public key of the payment hardware wallet, the transaction digital currency public key, and the remaining digital currency public key; Step 303-2 includes: Step 303-2-1: The hardware wallet constructs payload data, performs hash calculation on the constructed payload data to generate a hash value of the payload data, and uses the private key of the original digital currency stored in itself to perform signature calculation on the hash value of the payload data to generate a payload data signature value. In this embodiment, step 303-2-1 further includes: recording the payment operation type identifier value, payload data, and payload data signature value into the transaction log.

[0100] Step 303-2-2: The hardware wallet deletes the original digital currency, constructs the first transaction instruction response, and returns the first transaction instruction response to the bridge device, then returns to step 301; In this embodiment, the first transaction instruction response data includes: payload data constructed by the payment hardware wallet and payload data signature value.

[0101] Step 303-3: The hardware wallet obtains the payload data and payload data signature value through the second transaction instruction, and verifies whether the payload data is valid. If it is, then proceed to step 303-3-1; otherwise, clear the cache and return an error response to the host computer. In this embodiment, the second transaction instruction is an instruction sent by the bridge device to the hardware wallet that performs the receiving operation in the current digital currency transaction operation. The hardware wallet obtains the payload data and payload data signature value constructed by the payment hardware wallet in the current digital currency transaction operation from the second transaction instruction.

[0102] The hardware wallet verifies the validity of the payload data by verifying whether the transaction cryptocurrency public key in the payload data constructed by the payment hardware wallet is consistent with the public key generated by itself in step 303-1-2'. If they are consistent, the data is valid; otherwise, it is invalid.

[0103] Step 303-3-1: The hardware wallet verifies whether the payload data signature value is valid. If it is, proceed to step 303-3-2; otherwise, clear the cache and return an error response to the host computer. The hardware wallet verifies the validity of the payload data signature value by using the original digital currency public key of the payment wallet in the payload data constructed by the payment hardware wallet to verify the signature value of the payment wallet payload data. If the verification passes, it is valid; otherwise, it is invalid.

[0104] Step 303-3-2: The hardware wallet constructs its own payload data, and uses the first signature value and the second signature value of its own payload data to construct its own payload data signature value; The payload data constructed by the hardware wallet that receives the second transaction instruction includes: the original digital currency denomination, the transaction digital currency denomination, the merged digital currency denomination, the original digital currency public key, the transaction digital currency public key, and the merged digital currency public key in the receiving hardware wallet; Constructing its own payload data signature value specifically includes: performing a hash calculation on the payload data it constructs to generate a hash value for the payload data; using the private key of the original digital currency stored within itself to perform a signature calculation on the hash value of the payload data to generate a first signature value for the payload data; using the private key of the transaction digital currency to perform a signature calculation on the hash value of the payload data to generate a second signature value for the payload data; and concatenating the first signature value and the second signature value of the payload data to construct its own payload data signature value.

[0105] In this embodiment, step 303-3-2 further includes: recording the type identifier value, payload data, and payload data signature value of the payment operation into the transaction log.

[0106] Step 303-3-3: The hardware wallet deletes the original digital currency, constructs a second transaction instruction response, and returns the second transaction instruction response to the bridge device, then returns to step 301; In this embodiment, the second transaction instruction response data includes: payload data constructed by the receiving hardware wallet and payload data signature value.

[0107] Step 304: The hardware wallet stores the payment operation log in the cache, generates an additional proof record instruction response, and returns the additional proof record instruction response to the bridge device, then returns to step 301; Step 305: The hardware wallet generates a read record instruction response and returns the read record instruction response to the bridge device, then returns to step 301.

[0108] In this embodiment, the read record instruction response contains data related to digital currency transaction operations in the hardware wallet. The bridge device reads the data related to digital currency transaction operations in the hardware wallet from the hardware wallet through the read record instruction, based on the application file locator in the transaction initialization instruction response data returned by the hardware wallet.

[0109] In this embodiment, when the hardware wallet performs a payment operation, the read record instruction response returned to the bridge device includes the ID of the payment hardware wallet, the face value of the original digital currency stored in the payment hardware wallet, the public key of the original digital currency stored in the payment hardware wallet, and the transaction log of the payment hardware wallet.

[0110] When the hardware wallet performs a receiving operation, the read record instruction response returned to the bridge device includes the ID of the receiving hardware wallet, the public key of the transaction cryptocurrency, the face value of the original cryptocurrency stored in the receiving hardware wallet, the public key of the original cryptocurrency stored in the receiving hardware wallet, and the transaction log of the receiving hardware wallet. Example 4

[0111] See Figure 4 This illustrates the process of performing word segmentation operations on a hardware wallet as disclosed in Embodiment 4.

[0112] In this embodiment, the term "digital currency" refers to digital currency, which consists of: digital currency denomination and digital currency public / private key pair.

[0113] Token segmentation occurs when a hardware wallet performs a digital currency (referred to as "digital currency") payment operation. The key pair of the digital currency transaction is generated in the recipient's hardware wallet, and the public key in the key pair of the digital currency transaction is sent to the payer's hardware wallet through a bridge device for the payer's hardware wallet to use in constructing payload data.

[0114] A bridge device is a host computer used to enable data communication between the hardware wallet and the digital currency transaction process. In this embodiment, the bridge device is a smart POS machine, the payment hardware wallet is an application module in the smart POS machine, and the receiving hardware wallet is a hardware wallet card held by the user.

[0115] The hardware wallet card communicates with the POS machine containing the payment hardware wallet via NFC.

[0116] Preferably, the executable instructions of the payment hardware wallet in this embodiment include multiple application instructions, such as hardware wallet application instructions, VISA application instructions, PBOC application instructions, and MasterCard application instructions.

[0117] The specific execution process is as follows: Step 4-1: The payment hardware wallet receives the transaction initialization command sent by the bridge device; In this embodiment, the transaction initialization instruction includes: transaction currency denomination, transaction type, and transaction currency type.

[0118] Step 4-2: The payment hardware wallet checks the operation type and determines whether its own conditions meet the requirements for this transaction. If so, it proceeds to step 4-3; otherwise, it returns an error instruction to the bridge device, and the bridge device reports an error. In this embodiment, the payment hardware wallet determines that the operation it is performing is a payment operation based on the received initialization instruction, and sets the operation type identifier value to the segmented operation type identifier value; The payment hardware wallet determines whether it meets the conditions for this transaction by checking: its consecutive offline transaction count, the amount of currency in a single transaction, whether the cumulative amount of currency in consecutive offline transactions exceeds the limit, and whether it supports the currency for this transaction.

[0119] Step 4-3: The payment hardware wallet calculates the remaining digital currency value based on the transaction digital currency value, generates the public and private key pairs corresponding to the remaining digital currency, constructs a transaction initialization instruction response including AFL, and returns it to the bridge device; Preferably, in this embodiment, AFL is an application file locator, and AFL records the addresses of data related to payment hardware wallet transactions.

[0120] After receiving the transaction initialization instruction response, the bridge device extracts the application file locator from it and sends a read record instruction to the payment wallet based on the application file locator. Step 4-4: The payment hardware wallet receives the read record instruction sent by the bridge device, generates a read record response, and returns it to the bridge device. In this embodiment, the read record response is the transaction-related data of the payment hardware wallet obtained by the bridge device from the payment hardware wallet through the read record instruction by the AFL.

[0121] Preferably, in this embodiment, the data related to the payment hardware wallet transaction includes: payment hardware wallet ID, remaining digital currency denomination, public key of the remaining digital currency, transaction log of the payment hardware wallet, etc.

[0122] Steps 4-5: The payment hardware wallet receives the transaction instructions sent by the bridge device; In this embodiment, the transaction instruction sent by the bridge device includes the public key corresponding to the face value of the transaction currency generated by the receiving wallet.

[0123] Steps 4-6: The payment hardware wallet constructs payload data and uses the original digital currency private key in the payment hardware wallet to sign the hash value of the payload data, generating a payload data signature value. In this embodiment, the payload data constructed by the payment hardware wallet includes: the original digital currency denomination, the transaction digital currency denomination, the remaining digital currency denomination, the original digital currency public key, the transaction digital currency public key, and the remaining digital currency public key stored in the payment hardware wallet; Preferably, the hash value of the payload data is signed using the original digital currency private key in the payment wallet, and the specific steps to generate the payload data signature value include: The SHA256 hash algorithm is used to perform hash calculations on the payload data constructed by the payment hardware wallet to generate the hash value of the payer's payload data; The hash value of the payer's payload data is signed using ECDSA using the original digital currency private key in the payment hardware wallet to generate the payer's payload data signature value.

[0124] Steps 4-7: The payment hardware wallet records the operation type identifier value, payload data, and payload data signature value into the transaction log of the payment hardware wallet; Steps 4-8: The payment hardware wallet deletes the original currency pair from the storage area; Steps 4-9: The payment hardware wallet uses the payload data and payload data signature value to construct a transaction instruction response and returns it to the bridge device.

[0125] At this point, the payment hardware wallet has completed the payment operation. The remaining tokens in the payment hardware wallet will now be updated to the current tokens. Example 5

[0126] See Figure 5 This illustrates the process of performing word merging operations on a hardware wallet as disclosed in Embodiment 5.

[0127] In this embodiment, the term "digital currency" refers to digital currency, which consists of: digital currency denomination and digital currency public / private key pair.

[0128] Token merging occurs when a hardware wallet performs a digital currency (referred to as "digital currency") receiving operation. The key pair of the digital currency transaction is generated in the receiving party's hardware wallet, and the public key in the digital currency key pair is sent to the paying party's hardware wallet through a bridge device for the paying party's hardware wallet to use in constructing payload data.

[0129] A bridge device is a host computer used to enable data communication with a hardware wallet during digital currency transactions. In this embodiment, the bridge device is specifically a smart POS machine, and the payment hardware wallet and the receiving wallet are hardware wallet cards held by the user.

[0130] The receiving hardware wallet card and the payment hardware wallet card communicate with the smart POS machine via the 7816 communication protocol.

[0131] Preferably, the executable instructions of the payment hardware wallet in this embodiment include multiple application instructions, such as hardware wallet application instructions, VISA application instructions, PBOC application instructions, and MasterCard application instructions.

[0132] The specific execution process is as follows: Step 5-1: The receiving hardware wallet receives the transaction initialization command sent by the bridge device; In this embodiment, the transaction initialization instruction includes: transaction currency denomination, transaction type, and transaction currency type.

[0133] Step 5-2: The receiving hardware wallet checks the transaction type, sets the operation type identifier value to the merge operation type identifier value, and determines whether its own conditions meet the requirements of this transaction. If yes, proceed to step 5-3; otherwise, return an error instruction to the bridge device, and the bridge device will report an error. In this embodiment, the receiving hardware wallet determines whether its own conditions meet the requirements for this transaction by checking its consecutive offline transaction count, the amount of currency in a single transaction, whether the cumulative amount of currency in consecutive offline transactions exceeds the limit, and whether it supports the currency type for this transaction.

[0134] Step 5-3: The receiving hardware wallet generates a public and private key pair for the transaction digital currency, calculates the face value of the merged digital currency based on the face value of the transaction digital currency, and generates the public and private key pair corresponding to the merged digital currency and the public key of the transaction digital currency. Step 5-4: The receiving hardware wallet constructs transaction initialization instruction response data including AFL and returns it to the bridge device; Preferably, in this embodiment, AFL is an application file locator, and AFL records the addresses of data related to transactions of the receiving hardware wallet.

[0135] The bridge device obtains the application file locator from the transaction initialization instruction response, constructs a read record instruction based on the application file locator, and sends it to the receiving hardware wallet. Step 5-5: The payment hardware wallet receives the read record instruction sent by the bridge device, generates read record response data, and returns it to the bridge device; In this embodiment, the read record response is the data related to the transaction in the receiving hardware wallet that the bridge device obtains from the receiving hardware wallet by means of a read record instruction via AFL.

[0136] Preferably, in this embodiment, the data related to the transaction of the receiving hardware wallet includes: receiving hardware wallet ID, transaction digital currency public key, merged digital currency denomination, merged digital currency public key, and transaction log of the receiving hardware wallet, etc.

[0137] The bridge device constructs an append proof record instruction based on the read record response containing the transaction log of the payment wallet returned by the file locator and the payment wallet, and sends it to the receiving hardware wallet. The bridge device writes the transaction log of the payment wallet into the cache area of ​​the receiving hardware wallet through the append proof record instruction. Steps 5-6: The receiving hardware wallet receives the append proof record instruction sent by the bridge device, writes the transaction log of the payment wallet into the cache, and returns the append proof record instruction response to the bridge device. In this embodiment, additional proof record instruction response data indicates that the write cache was successfully written.

[0138] After receiving the additional proof record instruction response, the bridge device constructs a transaction instruction and sends it to the receiving hardware wallet; Steps 5-7: The receiving hardware wallet receives transaction instructions sent by the bridge device; In this embodiment, the transaction instruction sent by the receiving hardware wallet receiving bridge device includes payload data generated by the payment hardware wallet and payload data signature value.

[0139] Step 5-8: The receiving hardware wallet verifies whether the payload data and payload data signature value generated by the payment hardware wallet are valid. If they are, proceed to step 5-9; otherwise, delete the transaction log of the payment wallet stored in the cache and return an error instruction to the bridge device, and the bridge device will report an error. In this embodiment, the payload data generated by the payment hardware wallet includes: the original digital currency denomination in the payment wallet, the transaction digital currency denomination, the remaining digital currency denomination, the original digital currency public key of the payment wallet, the transaction digital currency public key, and the remaining digital currency public key; In this embodiment, the receiving hardware wallet verifies whether the payload data generated by the payment hardware wallet is valid. Specifically, the receiving hardware wallet verifies whether the public key of the transaction currency in the payload data generated by the payment hardware wallet is consistent with the public key generated in step 5-3. If they are consistent, it is valid; otherwise, it is invalid.

[0140] In this embodiment, the receiving hardware wallet verifies the validity of the payload data signature value generated by the paying hardware wallet. Specifically, the receiving hardware wallet uses the original digital currency public key of the paying wallet in the payload data generated by the paying hardware wallet to verify the signature value of the paying wallet payload data. If the verification passes, it is valid; otherwise, it is invalid.

[0141] Steps 5-9: Construct the payload data and payload data signature value of the receiving hardware wallet; In this embodiment, the payload data constructed by the receiving hardware wallet includes: the original digital currency denomination of the receiving wallet, the transaction digital currency denomination, the merged digital currency denomination, the original digital currency public key, the transaction digital currency public key, and the merged digital currency public key in the receiving wallet; In this embodiment, the process of constructing the payload data signature value in the payment hardware wallet is as follows: The SHA256 hash algorithm is used to perform hash calculations on the payload data constructed by the receiving hardware wallet to generate the hash value of the receiving party's payload data; Use the original digital currency private key in the receiving hardware wallet to perform an ECDSA signature on the hash value of the receiving payload data to generate the first payload data signature value of the receiving party. Use the private key of the transaction digital currency to perform an ECDSA signature on the hash value of the payee's payload data to generate a second payee payload data signature value; The first payload data signature value of the payee is combined with the second payload data signature value of the payee to generate the payee payload data signature value.

[0142] Steps 5-10: The receiving hardware wallet records the payload data constructed by the payment wallet, the payload data signature value of the payment wallet, the transaction log of the payment wallet, the payload data constructed by the receiving wallet, and the payload data signature value into the transaction log file of the receiving hardware wallet. Steps 5-11: Delete the original digital currency from the receiving hardware wallet; Steps 5-12: The receiving hardware wallet uses the payload data and payload data signature value built by the receiving wallet to construct a transaction instruction response and return it to the bridge device.

[0143] In this embodiment, the method further includes: after the bridge device is connected to the network, synchronizing the saved transaction logs of the payment wallet, the payload data of the payment wallet, the signature value of the payload data of the payment wallet, the payload data of the receiving wallet, and the signature value of the payload data of the receiving wallet to the hardware wallet backend server.

[0144] In this embodiment, the payment hardware wallet can also synchronize the word conversion operation log (transaction log) when the network is offline to the hardware wallet backend server after connecting to the network. Example 6

[0145] See Figure 6 The diagram shows a structural block diagram of the hardware wallet device provided in Embodiment Six of the present invention.

[0146] This embodiment provides a hardware wallet device, which is physically a smart card conforming to the ISO / IEC 7816 standard and has a built-in security chip. It can be used to securely perform the splitting and merging of digital assets in an offline environment.

[0147] The hardware wallet device includes a processor unit 601, a security component 602, a memory unit 603, a communication interface 604, a display unit 605, and an input unit 606.

[0148] Processor unit 601 is responsible for executing token transaction logic, processing communication protocols, managing storage resources, and coordinating the operation of various components and units. Processor unit 601 can employ a low-power microcontroller or a dedicated security chip.

[0149] Security component 602, connected to processor unit 601, provides a secure execution environment for token keys and cryptographic operations. It generates token public-private key pairs, constructs payload data, and includes a cryptographic operation engine for performing ECDSA signing, hashing, and key generation. Security component 602 internally contains a secure storage area for storing token private keys and sensitive data; it also includes a cryptographic operation engine for performing ECDSA signing, hashing, and key generation. Security component 602 employs physical isolation and tamper-proof technologies to ensure the security of its internal data.

[0150] Memory unit 603 is connected to processor unit 601 and includes a non-volatile storage medium for storing fields such as lexical structure data, lexical conversion operation type, lexical conversion operation log, payload data, payload data signature value, authentication data written after networking, and system configuration parameters. Memory unit 603 employs encrypted storage technology to prevent data from being illegally read or tampered with. Memory unit 603 also includes a volatile buffer for temporarily storing lexical conversion operation log data written by the host computer from another hardware wallet during the merging operation.

[0151] The communication interface 604 is connected to the processor unit 601 and supports multiple near-field communication protocols. The communication interface 604 may include an NFC (Near Field Communication) module, supporting ISO / IEC 14443 and ISO / IEC 18092 standards; it may also include a Bluetooth Low Energy (BLE) module, supporting data interaction with smart terminal devices; and it may include a USB interface, supporting data synchronization with a PC. When connected to a network, the communication interface 604 is used for data transmission with the hardware wallet's backend system.

[0152] The display unit 605 is connected to the processor unit 601 and is used to display interface content such as word balance, transaction word value, transaction information, and operation prompts to the user. The display unit 605 can be an LCD screen or an e-ink screen.

[0153] The input unit 606 is connected to the processor unit 601 and is used to receive user operation commands. The input unit 606 may include touch buttons, physical buttons, or a gesture recognition module.

[0154] The hardware wallet device in this embodiment also includes the following functional units: Application File Locator Generation Unit: This is a logical functional unit executed by the processor unit. When performing a split operation, the application file locator generation unit generates a first application file locator, which points to an address storing data related to the operation of the first hardware wallet (including hardware wallet ID, original token values, original token public keys, and operation logs). When performing a merge operation, the application file locator generation unit generates a second application file locator, which points to an address storing data related to the operation of the second hardware wallet (including wallet ID and generated transformation token public keys).

[0155] The offline transaction counter unit records the cumulative number of offline transactions. This counter increments after each lexical operation, and when the counter reaches a preset offline transaction limit, the hardware wallet prompts for online synchronization.

[0156] The lexical value limit verification unit is used to verify whether the transaction amount exceeds the preset lexical value limit and single transaction limit before verifying lexical operations. This unit ensures that lexical operations comply with the risk control strategies set by the backend system.

[0157] The lexical conversion operation log management unit is used to maintain the read and write operations of the lexical conversion operation log file. The lexical conversion operation log file uses a predefined data format and short file identifier addressing, and supports appending and batch reading operations of records.

[0158] The cryptographic service unit, encapsulated within the security component 502, provides the cryptographic services required for token operations, including key generation, ECDSA signing, hash operations, etc.

[0159] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

[0160] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented using software programs, implementation can be, in whole or in part, in the form of a computer program product. This computer program product includes one or more computer programs. When the computer program is loaded and executed on an electronic device, all or part of the processes or functions described in the embodiments of this application are generated. The computer program can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one base station, electronic device, server, or data center to another via wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to the electronic device or a data storage device including one or more servers, data centers, etc., that can be integrated using media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state disk (SSD)). In the embodiments of this application, the electronic device may include the system described above.

[0161] Although this application has been described herein in conjunction with various embodiments, those skilled in the art, by reviewing the accompanying drawings, disclosure, and appended claims, will understand and implement other variations of the disclosed embodiments in carrying out the claimed application. In the claims, the word "comprising" does not exclude other components or steps, and "a" or "an" does not exclude a plurality. A single processor or other unit can implement several functions listed in the claims. While different dependent claims may recite certain measures, this does not mean that these measures cannot be combined to produce good results.

[0162] Although this application has been described in conjunction with specific features and embodiments, it is obvious that various modifications and combinations can be made thereto without departing from the spirit and scope of this application. Accordingly, this specification and drawings are merely exemplary illustrations of this application as defined by the appended claims, and are considered to cover any and all modifications, variations, combinations, or equivalents within the scope of this application. Clearly, those skilled in the art can make various alterations and modifications to this application without departing from the spirit and scope of this application. Thus, if such modifications and modifications of this application fall within the scope of the claims of this application and their equivalents, this application is also intended to include such modifications and modifications.

Claims

1. A method for operating an offline operating system for a hardware wallet, applied to a system including a first hardware wallet, a second hardware wallet, and a host computer, characterized in that, The first hardware wallet stores a first original lexical unit, and the second hardware wallet stores a second original lexical unit. Each lexical unit includes a lexical unit value and a lexical unit public / private key pair. The method includes the following steps: Step 1: The first hardware wallet receives a first instruction from the host computer for a segmented word conversion operation and executes step 2-1; the second hardware wallet receives a first instruction from the host computer for a merged word conversion operation and executes step 2-1'. Step 2-1: The first hardware wallet obtains the converted lexical value from the first instruction of the lexical conversion operation, determines whether the data stored in itself can be used to execute the first instruction of the lexical conversion operation, and if so, generates a first application file locator and returns the first application file locator to the host computer, and executes step 2-2; otherwise, it reports an error. Step 2-1': The second hardware wallet obtains the transformed token value from the first instruction of the token transformation operation, determines whether its stored data can be used to execute the first instruction of the token transformation operation, and if so, generates a public-private key pair of transformed tokens and a second application file locator, and returns the second application file locator to the host computer. The host computer reads the transformed token public key through the second application file locator, uses the transformed token public key to construct the second instruction of the token transformation operation and sends it to the first hardware wallet, and executes step 2-2; otherwise, an error is reported. Step 2-2: The first hardware wallet receives the second instruction for lexical conversion operation sent by the host computer, constructs the first payload data, and signs the hash value of the first payload data using the first original lexical private key to generate the first payload data signature value. Steps 2-3: The first hardware wallet deletes the first original word element; Steps 2-4: The first hardware wallet returns the first payload data and the first payload data signature value to the host computer. The host computer uses the first payload data and the first payload data signature value to construct a third instruction for lexical conversion operation and sends it to the second hardware wallet. Steps 2-5: The second hardware wallet receives the third instruction of the lexical conversion operation, obtains the first payload data and the first payload data signature value from the third instruction of the lexical conversion operation, and verifies the first payload data. If the verification is successful, proceed to step 2-6; otherwise, report an error. Step 2-6: The second hardware wallet verifies the signature value of the first payload data. If the verification passes, proceed to step 2-7; otherwise, report an error. Steps 2-7: The second hardware wallet constructs the second payload data and calculates the hash value. It uses the second original token private key to perform a signature calculation on the hash value of the second payload data to generate a first signature value of the second payload data. It uses the transformed token private key to perform a signature calculation on the hash value of the second payload data to generate a second signature value of the second payload data. It uses the first signature value of the second payload data and the second signature value of the second payload data to construct a second payload data signature value. Steps 2-8: The second hardware wallet deletes the converted tokens and the second original tokens; Steps 2-9: The second hardware wallet returns the second payload data and the second payload data signature value to the host computer; The method further includes: when the first hardware wallet receives the first instruction of the word conversion operation or the second instruction of the word conversion operation, constructing a first new word; When the second hardware wallet receives the first instruction or the third instruction of the word conversion operation, it constructs a second new word.

2. The method according to claim 1, characterized in that, The first new lexical element includes a first new lexical element value and a first new lexical element public / private key pair, wherein the first new lexical element value is the difference between the first original lexical element value and the transformed lexical element value; The second new lexical element includes a second new lexical element value and a second new lexical element public / private key pair. The second new lexical element value is the sum of the second original lexical element value and the transformed lexical element value.

3. The method according to claim 1, characterized in that, The first application file locator stores address information related to the lexical transformation operation of the first hardware wallet. The data related to the lexical transformation operation of the first hardware wallet includes: the ID of the first hardware wallet, the original lexical value of the first hardware wallet, the original lexical public key of the first hardware wallet, and the lexical transformation operation log of the first hardware wallet.

4. The method according to claim 3, characterized in that, Also includes: The host computer, based on the first application file locator, reads the ID of the first hardware wallet, the original token value of the first hardware wallet, the original token public key of the first hardware wallet, and the token conversion operation log of the first hardware wallet from the first hardware wallet through a read record instruction.

5. The method according to claim 1, characterized in that, The second application file locator stores address information related to the lexical transformation operation of the second hardware wallet. The lexical transformation operation related data includes: the ID of the second hardware wallet, the public key of the transformed lexical in the public-private key pair, the original lexical value of the second hardware wallet, the original lexical public key of the second hardware wallet, and the lexical transformation operation log of the second hardware wallet.

6. The method according to claim 5, characterized in that, The host computer, based on the second application file locator, reads the ID of the second hardware wallet, the public key of the transformed token in the public-private key pair, the original token value of the second hardware wallet, the original token public key of the second hardware wallet, and the token transformation operation log of the second hardware wallet from the second hardware wallet through a read record instruction.

7. The method according to claim 1, characterized in that, Step 2-2 specifically includes: Step 2-2-1: When the first hardware wallet receives the second instruction for word conversion operation sent by the host computer, it obtains the public key of the converted word through the second instruction for word conversion operation. Step 2-2-2: The first hardware wallet constructs first payload data including the first original lexical value, the transformed lexical value, the first new lexical value, the first original lexical public key, the transformed lexical public key, and the first new lexical public key; Step 2-2-3: The first hardware wallet performs a hash calculation on the first payload data to generate a hash value for the first payload data; Step 2-2-4: The first hardware wallet uses the first original token private key to perform a signature calculation on the hash value of the first payload data to generate the first payload data signature value; Step 2-2-5: The first hardware wallet writes the first payload data and the first payload data signature value into the lexical conversion operation log of the first hardware wallet.

8. The method according to claim 4, characterized in that, Before steps 2-5, the host computer further includes: writing the lexical conversion operation log of the first hardware wallet into the cache area of ​​the second hardware wallet by appending a proof record instruction, and the second hardware wallet returns a save response to the host computer.

9. The method according to claim 8, characterized in that, Steps 2-5 specifically include: When the second hardware wallet receives the third instruction for lexical conversion operation sent by the host computer, it obtains the first payload data and the first payload data signature value from the third instruction for lexical conversion operation, and verifies whether the public key of the converted lexical in the first payload data is consistent with the public key of the converted lexical generated by the second hardware wallet; if they are consistent, steps 2-6 are executed; otherwise, an error is reported, and the lexical conversion operation log of the first hardware wallet stored in the cache area of ​​the second hardware wallet is deleted. Steps 2-6 specifically include: The second hardware wallet uses the first original token public key in the first payload data to verify the signature value of the first payload data. If the verification is successful, steps 2-7 are executed; otherwise, an error is reported, and the token conversion operation log of the first hardware wallet stored in the cache of the second hardware wallet is deleted. Steps 2-7 specifically include: The second hardware wallet constructs second payload data comprising a second original lexical value, the transformed lexical value, a second new lexical value, a second original lexical public key, a second new lexical public key, and the transformed lexical public key. A hash algorithm is used to calculate a hash value for the second payload data. The hash value of the second payload data is signed using the second original lexical private key to generate a first signature value for the second payload data. The hash value of the second payload data is then signed using the transformed lexical private key to generate a second signature value for the second payload data. Finally, the first and second signature values ​​of the second payload data are used to construct a second payload data signature value.

10. The method according to claim 9, characterized in that, Steps 2-7 further include: writing the first payload data, the first payload data signature value, the lexical conversion operation log of the first hardware wallet, the second payload data, and the second payload data signature value into the lexical conversion operation log of the second hardware wallet.

11. The method according to claim 9, characterized in that, Steps 2-7 are followed by: after the host computer and / or the second hardware wallet are connected to the network, the first payload data, the first payload data signature value, the word conversion operation log of the first hardware wallet, the second payload data, and the second payload data signature value are synchronized to the hardware wallet backend server.

12. The method according to claim 11, characterized in that, Steps 2-7 are followed by the following: the hardware wallet backend server writes the first payload data, the first payload data signature value, the first hardware wallet lexical conversion operation log, the second payload data, and the second payload data signature value into the authentication data storage area. The authentication data includes a lexical conversion value field, a lexical conversion operation type field, a lexical conversion operation log field, a payload data field, and a payload data signature value field.

13. The method according to claim 1, characterized in that, The host computer is a smart terminal device, including a mobile phone or a POS machine, and the hardware wallet is a smart card or an application module unit in the host computer.

14. A method for offline operation of a hardware wallet, characterized in that, The hardware wallet stores original tokens, each token containing a token value and a token public / private key pair. The method includes the following steps: Step 101: The hardware wallet receives instructions from the host computer; Step 102: The hardware wallet determines the instruction type. When the instruction is a first instruction for word conversion operation, execute step 103-1; when the instruction is a second instruction for word conversion operation, execute step 103-2; when the instruction is a third instruction for word conversion operation, execute step 103-3; when the instruction is an instruction to append a proof record, execute step 103-4; when the instruction is an instruction to read a record, execute step 103-5. Step 103-1: The hardware wallet determines the operation type. If it is a splitting operation, then step 103-1-1 is executed; if it is a merging operation, then step 103-1-1' is executed. Step 103-1-1: The hardware wallet obtains the converted word value and determines whether the segmentation operation can be performed. If so, proceed to step 103-1-2; otherwise, return an error response to the host computer. Step 103-1-2: The hardware wallet generates an application file locator and returns the application file locator to the host computer; Step 103-1-1': The hardware wallet obtains the converted word value and determines whether the merging operation can be performed. If so, step 103-1-2' is executed; otherwise, an error response is returned to the host computer. Step 103-1-2': The hardware wallet generates a public-private key pair of conversion tokens and an application file locator, and returns the application file locator to the host computer; Step 103-2: The hardware wallet constructs payload data and calculates a hash value, signs the hash value of the payload data using the original token private key, and generates a payload data signature value; deletes the saved original tokens, and returns the payload data and the payload data signature value to the host computer. Step 103-3: The hardware wallet obtains payload data and payload data signature value through the third operation instruction, and verifies whether the payload data is valid. If it is, then step 103-3-1 is executed; otherwise, an error response is returned to the host computer. Step 103-3-1: The hardware wallet verifies whether the payload data signature value is valid. If it is, proceed to step 103-3-2; otherwise, return an error response to the host computer. Step 103-3-2: The hardware wallet constructs its own payload data and calculates the first signature value and the second signature value of its own payload data, and uses the first signature value and the second signature value of its own payload data to construct the signature value of its own payload data; Step 103-3-3: The hardware wallet deletes the original tokens stored therein and returns its own payload data and the signature value of the payload data to the host computer. Step 103-4: Obtain the operation log from the hardware wallet acquisition instruction, store the operation log in the cache area, and return a storage response to the host computer; Step 103-5: The hardware wallet returns relevant data on hardware wallet lexical conversion operation to the host computer.

15. A hardware wallet device, characterized in that, The hardware wallet device is used to perform the method of claim 1, the hardware wallet device comprising: The processor unit is used to construct payload data and calculate new lexical values; A security component, connected to the processor unit, is used to generate and store token public-private key pairs, calculate the hash value of payload data, generate payload data signature value, and verify payload data signature value. A memory, connected to the processor unit, is used to store data related to hardware wallet lexical conversion operations; A communication interface, connected to the processor unit, is used for data communication with a host computer.

16. The hardware wallet device according to claim 15, characterized in that: The security component includes a secure storage area for storing the public-private key pair of the term; The memory includes a designated file area for storing lexical conversion operation log files, which are addressed using short file identifiers.

17. The hardware wallet device according to claim 16, characterized in that: The security component is also used to delete the original token private key from the secure storage area after calculating the payload data signature value.

18. The hardware wallet device according to claim 15, characterized in that: The memory also includes a cache area for caching word conversion operation log data from the host computer.

19. The hardware wallet device according to claim 15, characterized in that: The communication interface supports contact communication and / or contactless communication.

20. The hardware wallet device according to claim 15, characterized in that, Also includes: Application file locator generation unit, used to generate application file locators; The application file locator stores address information of data related to hardware wallet lexical conversion operations.

21. The hardware wallet device according to claim 15, characterized in that, Also includes: A lexical conversion operation counter is used to record the number of lexical conversions. The lexical conversion limit parameter unit is used to set the upper limit of the number of lexical conversions; Before performing the word conversion operation, the processor unit verifies the legality of the word conversion operation based on the maximum number of word conversion operations in the offline environment. When the word conversion operation counter reaches the maximum number of word conversion operations, the processor unit prompts the network to connect.

22. The hardware wallet device according to claim 15, characterized in that, Also includes: A lexical value counter is used to record the lexical values ​​of lexical transformation operations; The lexical value limit parameter unit is used to set the maximum converted lexical value for a single lexical conversion operation and the cumulative converted lexical value for lexical conversion operations; Before performing the word conversion operation, the processor unit verifies the legality of the word conversion operation based on the maximum converted word value of a single conversion operation in the offline environment and the cumulative converted word value of the word conversion operation.

23. A computer system comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the steps of the method according to any one of claims 1-14.

Images