Digital currency hard wallet system and double-offline information secure storage and synchronous uploading method thereof

Abstract

The invention relates to the field of digital currency hard wallets, in particular to a digital currency hard wallet system and a double-offline information secure storage and synchronous uploading method thereof, and the method comprises the steps: responding to the generation of offline transaction information, and judging whether a ciphertext encryption key exists in a security chip SE or not; if not, randomly generating a plaintext encryption key, encrypting the plaintext encryption key to form a ciphertext encryption key, and storing the ciphertext encryption key in a security chip SE; if the off-line transaction information exists, decrypting a ciphertext encryption key in the SE to obtain a plaintext encryption key, and encrypting the off-line transaction information by using the plaintext encryption key to form an off-line transaction information ciphertext; and transmitting the off-line transaction information ciphertext to the MCU, and storing the off-line transaction information ciphertext in the MCU. According to the invention, a large amount of digital currency offline transaction information can be safely stored.

Description

Technical Field

[0001] The present application relates to the field of digital currency hard wallets, and in particular to a digital currency hard wallet system, a digital currency hard wallet dual offline information secure storage method, and a digital currency hard wallet dual offline information synchronous upload method. Background Art

[0002] Digital currency electronic payment DCEP requires support for dual offline payment scenarios, that is, accounting is first performed when both the payee and the payee are offline, and after the network is connected, the closed-loop transaction is completed by deferred payment, and the business system then settles with the digital currency center.

[0003] Based on the risk control system, the transaction time limit for dual offline payment is 4 hours and the number of times is 10. In addition, in the case of dual offline payment, the digital currency hard wallet needs to store offline transaction data such as balance voucher list and transaction flow list information locally. These data are personal privacy information and the risk of leakage needs to be reduced as much as possible. However, the amount of data may be large, and the local security chip SE has a small memory and cannot store such a large amount of data. Therefore, due to the storage space limitation of the security chip SE, the digital currency hard wallet cannot store large amounts of confidential sensitive data while ensuring security.

[0004] Therefore, how to safely store large amounts of digital currency payment data is a technical problem that those skilled in the art need to solve. Summary of the invention

[0005] The present application provides a digital currency hard wallet system, a digital currency hard wallet dual offline information secure storage method and a digital currency hard wallet dual offline information synchronous upload method to securely store a large amount of digital currency offline payment data.

[0006] In order to solve the above technical problems, this application provides the following technical solutions:

[0007] A method for securely storing dual offline information of a digital currency hard wallet comprises the following steps: step S110, in response to generating offline transaction information, determining whether a ciphertext encryption key exists in a security chip SE; step S120, if not, randomly generating a plaintext encryption key, encrypting the plaintext encryption key to form a ciphertext encryption key, and storing the ciphertext encryption key in the security chip SE; step S130, if existing, decrypting the ciphertext encryption key in the security chip SE to obtain a plaintext encryption key, and applying the plaintext encryption key to encrypt offline transaction information to form an offline transaction information ciphertext; step S140, transmitting the offline transaction information ciphertext to an MCU, and storing the offline transaction information ciphertext in the MCU.

[0008] In the above-mentioned digital currency hard wallet dual offline information security storage method, preferably, step S120 includes the following sub-steps: step S121, generate a true random number Mask of m bytes, and randomly generate plaintext encryption keys Key1 and Key2 with a byte length of LenKey; step S122, divide the plaintext encryption keys Key1 and Key2 into b=(LenKey+m-1) / m byte blocks according to m bytes; step S123, perform an XOR operation on each byte block Ki and the true random number Mask to generate an encrypted byte block ki; step S124, Concatenate the encrypted byte blocks ki in the order of generation to obtain ciphertext encryption keys en_Key1 and en_Key2 with a byte length of LenKey; step S125, generate a CRC check code through the true random number Mask, the byte length LenKey, the ciphertext encryption key en_Key1, and the ciphertext encryption key en_Key2, and store the CRC check code, the true random number Mask, the byte length LenKey, the ciphertext encryption key en_Key1, the ciphertext encryption key en_Key2 and the key state identifier KeyState as a key storage unit.

[0009] In the method for securely storing dual offline information of a digital currency hard wallet as described above, preferably, the offline transaction information includes: a balance voucher list BalVoucherM and a transaction flow list TransBillM.

[0010] In the method for secure storage of dual offline information of a digital currency hard wallet as described above, preferably, step S130 includes the following sub-steps: step S131, verifying the Crc check code to determine whether the key storage unit has been tampered with; step S132, if tampered with, terminating the operation; step S133, if not tampered with, dividing the ciphertext encryption keys en_Key1 and en_Key2 in the key storage unit into b encrypted byte blocks ki respectively, and performing XOR operation on each encrypted byte block ki and the true random number Mask in turn to generate a byte block Ki; step S134, concatenating the byte blocks Ki in the order of generation to obtain plaintext encryption keys Key1 and Key2; step S135, encrypting the balance voucher list BalVoucherM with the plaintext encryption key Key1 to generate the balance voucher list ciphertext BalVoucherC, and encrypting the transaction flow list TransBillM with the plaintext encryption key Key2 to generate the transaction flow list ciphertext TransBillC.

[0011] In the method for secure storage of dual offline information of a digital currency hard wallet as described above, preferably, if the data length of the balance voucher list BalVoucherM is less than an integer multiple of the block size of the symmetric encryption algorithm used by the security chip SE to encrypt offline transaction information, the balance voucher list BalVoucherM is padded with '00' until its data length is an integer multiple of the block size of the symmetric encryption algorithm used by the security chip SE to encrypt offline transaction information; if the data length of the transaction flow list TransBillM is less than an integer multiple of the block size of the symmetric encryption algorithm used by the security chip SE to encrypt offline transaction information, the transaction flow list TransBillM is padded with '00' until its data length is an integer multiple of the block size of the symmetric encryption algorithm used by the security chip SE to encrypt offline transaction information; then, the plaintext encryption keys Key1 and Key2 are used to encrypt the balance voucher list BalVoucherM and the transaction flow list TransBillM respectively to generate the balance voucher list ciphertext BalVoucherC and the transaction flow list ciphertext TransBillC.

[0012] In the method for securely storing dual offline information of a digital currency hard wallet as described above, preferably, the ciphertext of the balance voucher list BalVoucherC and the ciphertext of the transaction flow list TransBillC are both transmitted to the MCU for storage; and the real length BalVoucherLen of the balance voucher list BalVoucherM and the real length TransBillLen of the transaction flow list TransBillM are transmitted to the MCU for storage.

[0013] A method for synchronously uploading dual offline information of a digital currency hard wallet comprises the following steps: step S505, a wallet APP sends a synchronization operation instruction to a security chip SE; step S510, in response to receiving the synchronization operation instruction, the security chip SE sends a basic response information + status code 9200 to the wallet APP; step S515, the security chip SE decrypts the ciphertext encryption key stored therein to obtain a plaintext encryption key; step S520, in response to receiving the basic response information and status code 9200, the wallet APP sends the basic response information to the institution background, and sends a DC / EP response command to the security chip SE according to the status code 9200; step S525, in response to receiving the DC / EP response command In step S530, the MCU sends the ciphertext block data of the offline transaction information ciphertext to the security chip SE; in step S535, the security chip SE decrypts the ciphertext block data of the offline transaction information ciphertext using the plaintext encryption key to obtain the block data of the offline transaction information, and sends the block data of the offline transaction information + status code 9200 to the wallet APP; in step S540, in response to receiving the block data and status code 9200 of the offline transaction information, the wallet APP sends the block data of the offline transaction information to the institution background, and sends the DC / EP response command to the security chip SE according to the status code 9200; in step S5 45. In response to receiving the DC / EP response command, the security chip SE requests the ciphertext block data of the offline transaction information ciphertext from the MCU; step S550, the MCU sends the last ciphertext block data of the offline transaction information ciphertext with an end mark to the security chip SE; step S555, the security chip SE uses the plaintext encryption key to decrypt the last ciphertext block data of the offline transaction information ciphertext, obtains the last block data of the offline transaction information, and sends the last block data of the offline transaction information and MAC3+status code 9000 to the wallet APP, and updates the transaction status to pending confirmation; step S560, in response to receiving the last block data of the offline transaction information and MAC3 and status code 9000, the wallet APP sends the last block data and MAC3 of the offline transaction information to the institution background, and no longer sends the DC / EP response command to the security chip SE according to the status code 9000; step S565, in response to receiving the new coin string DC obtained by the institution background according to the block data processing of all offline transaction information, the wallet APP sends a synchronization completion instruction to the security chip SE to issue the new coin string DC; step S570, the security chip SE stores the new coin string DC, updates the transaction status to completion, deletes the ciphertext encryption key, and requests the MCU to delete the offline transaction information; step S575, in response to receiving the request to delete the offline transaction information, the MCU deletes the offline transaction information stored therein;Step S580, in response to the security chip SE updating the transaction status to completion, the security chip SE sends synchronization update completion response data to the wallet APP; Step S585, the wallet APP transmits the synchronization update completion response data to the institution backend. ;

[0014] In the method for synchronously uploading dual offline information of a digital currency hard wallet as described above, preferably, the MCU divides the offline transaction information ciphertext into a plurality of ciphertext block data in sequence according to the total number of offline transactions TransactionNum.

[0015] In the method for synchronously uploading dual offline information of a digital currency hard wallet as described above, preferably, the offline transaction information includes: a balance voucher list BalVoucherM and a transaction flow list TransBillM, and the security chip SE will determine whether it contains padding data based on the real length BalVoucherLen of the recorded balance voucher list BalVoucherM and the real length TransBillLen of the transaction flow list TransBillM. If there is padding data, the padding data will be cleared and then responded to the wallet APP.

[0016] A digital currency hard wallet system, comprising: a digital currency hard wallet and a wallet APP; the digital currency hard wallet comprises: a digital currency hard wallet body, an MCU and a security chip SE, wherein the MCU and the security chip SE are located inside the digital currency hard wallet body; the wallet APP runs on a terminal; and the MCU, the security chip SE and the wallet APP execute any one of the above methods.

[0017] Compared with the above background technology, the present application adopts a distributed storage method, stores the ciphertext encryption key on the security chip SE, and stores the offline transaction information ciphertext on the MCU. The offline transaction information generated by each offline transaction is encrypted by the plaintext encryption key and transmitted from the security chip SE to the MCU for storage in a certain format. After connecting to the network, the MCU transmits all offline transaction information in blocks to the security chip SE in sequence. The security chip SE decrypts the received data block using the plaintext encryption key to obtain the transaction information plaintext, and transmits the transaction information plaintext to the institution's backend. Therefore, the present application can not only store the massive offline transaction information generated by digital currency payment, but also ensure the security of offline transaction information storage. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in the present invention. For ordinary technicians in this field, other drawings can also be obtained based on these drawings.

[0019] Figure 1 It is a flow chart of the method for securely storing dual offline information of a digital currency hard wallet provided by this application;

[0020] Figure 2 It is a schematic diagram of a digital currency hard wallet provided by this application;

[0021] Figure 3 It is a flowchart of the formation and storage of the encryption key provided by the present application;

[0022] Figure 4 It is a flow chart of the formation and storage of the ciphertext of offline transaction information provided by this application;

[0023] Figure 5 This is a flow chart of the method for synchronously uploading dual offline information of a digital currency hard wallet provided by this application. DETAILED DESCRIPTION

[0024] The embodiments of the present application are described in detail below, and examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present application, and cannot be interpreted as limiting the present application.

[0025] Embodiment 1

[0026] like Figure 1 As shown, the present application provides a method for securely storing dual offline information of a digital currency hard wallet, comprising the following steps:

[0027] Step S110: In response to generating the offline transaction information, determining whether there is a ciphertext encryption key in the security chip SE.

[0028] like Figure 2 As shown, the digital currency hard wallet 200 includes: a digital currency hard wallet body 230, an MCU210 and a security chip SE220; the MCU210 and the security chip SE220 are located inside the digital currency hard wallet body 230, and the digital currency hard wallet body 230 can be a terminal such as a card, a bracelet, or a keychain. Among them, the security chip SE220 has software and hardware security support and can be used to store confidential data, but the storage space is relatively small; the storage space of MCU210 is large, but it cannot be used to store confidential data. In this application, the MCU210 with a large storage space is used to store a large amount of offline transaction information (balance voucher list, transaction flow list), so that the transaction time limit and transaction number restrictions of offline payment can be relaxed, but the security of offline transaction information stored on MCU210 needs to be guaranteed.

[0029] In an offline situation, when a transaction occurs in the digital currency hard wallet 200, such as a card swiping transaction, offline transaction information M will be generated. In response to the generation of the offline transaction information M, the security chip SE220 determines whether there is a ciphertext encryption key inside it.

[0030] Since the offline transaction information M stored in MCU210 in this application includes: balance voucher list BalVoucherM and transaction flow list TransBillM, two ciphertext encryption keys en_Key1 and en_Key2 are stored in the security chip SE220 in this application. Ciphertext encryption key en_Key1 is the ciphertext encrypted by plaintext encryption key Key1, and its byte number can be LenKey. Ciphertext encryption key en_Key2 is the ciphertext encrypted by plaintext encryption key Key2, and its byte number can also be LenKey. Therefore, when the offline transaction information M is subsequently encrypted, the balance voucher list BalVoucherM is encrypted using the plaintext encryption key Key1 restored by the ciphertext encryption key en_Key1, and the transaction flow list TransBillM is encrypted using the plaintext encryption key Key2 restored by the ciphertext encryption key en_Key2.

[0031] In addition, the security chip SE220 also stores the true random number Mask of the encrypted plaintext encryption keys Key1 and Key2, and the number of bytes of the true random number Mask can be 4; the security chip SE220 also stores the byte length LenKey of the ciphertext encryption keys en_Key1 and en_Key2, and LenKey is determined by the encryption algorithm used. For example, if the SM4 encryption algorithm is used, LenKey = 16, and the number of bytes occupied is 1. The security chip SE220 also stores a CRC check code, which may be 2 bytes. The CRC check code is generated by (true random number Mask||byte length LenKey||ciphertext encryption key en_Key1||ciphertext encryption key en_Key2). Before decrypting the ciphertext encryption key en_Key1 and the ciphertext encryption key en_Key2 to generate the plaintext encryption keys Key1 and Key2, a CRC check is performed on (true random number Mask||byte length LenKey||ciphertext encryption key en_Key1||ciphertext encryption key en_Key2) to prevent data tampering. The security chip SE220 also stores a key status identifier KeyState, which may be 1 byte. The key status identifier KeyState is used to mark whether the storage of the group of key storage units is completed. The group of key storage units refers to the CRC check code, true random number Mask, byte length LenKey, encryption key en_Key1 and encryption key en_Key2.

[0032] Specifically, in the security chip SE220, the key is stored in the key storage unit format of the symmetric encryption algorithm, as shown in Table 1.

[0033]

[0034] Since a group of key storage units is stored in the security chip SE220, the key status identifier KeyState in the group of key storage units can be determined. If the key status identifier KeyState indicates that the storage of the group of key storage units is completed, it means that the ciphertext encryption keys en_Key1 and en_Key2 exist in the security chip SE220. If the key status identifier KeyState indicates that the storage of the group of key storage units is not completed, it means that the ciphertext encryption keys en_Key1 and en_Key2 do not exist in the security chip SE220.

[0035] Step S120: If it does not exist, randomly generate a plaintext encryption key, encrypt the plaintext encryption key to form a ciphertext encryption key, and store the ciphertext encryption key in the security chip SE220.

[0036] If the ciphertext encryption key does not exist in the security chip SE220, a plaintext encryption key is randomly generated, and then a true random number generator is used to generate a true random number. The security chip SE220 uses the true random number to encrypt the plaintext encryption key to form a ciphertext encryption key, and the ciphertext encryption key is stored in the security chip SE220 to utilize the security of the security chip SE220 to more securely store confidential data.

[0037] Specifically, Figure 3 As shown, step S120 includes the following sub-steps:

[0038] Step S121, generate a true random number Mask of m bytes, and randomly generate plaintext encryption keys Key1 and Key2 with a byte length of LenKey.

[0039] Randomly generate plaintext encryption keys Key1 and Key2, the byte length of the plaintext encryption keys Key1 and Key2 are both LenKey, and use a true random number generator to generate an m-byte true random number Mask.

[0040] Step S122: divide the plaintext encryption keys Key1 and Key2 into b=(LenKey+m-1) / m byte blocks according to m bytes.

[0041] The plaintext encryption keys Key1 and Key2 with a byte length of LenKey are divided into b = (LenKey + m-1) / m byte blocks according to m bytes, and Ki is used to represent the i-th byte block.

[0042] Step S123: Perform an XOR operation on each byte block Ki and the true random number Mask to generate an encrypted byte block ki.

[0043] Each byte block Ki of the plaintext encryption key Key1 is XORed with the true random number Mask to generate an encrypted byte block ki, where 1≤i<b. If the last byte block, that is, the bth byte block, is less than m bytes, the bytes of the bth byte block are XORed with the high-order bytes of the true random number Mask.

[0044] Each byte block Ki of the plaintext encryption key Key2 is XORed with the true random number Mask to generate an encrypted byte block ki, where 1≤i<b. If the last byte block, that is, the bth byte block, is less than m bytes, the bytes of the bth byte block are XORed with the high-order bytes of the true random number Mask.

[0045] Step S124: Concatenate the encrypted byte blocks ki in the order of generation to obtain ciphertext encryption keys en_Key1 and en_Key2 with a byte length of LenKey.

[0046] All the encrypted byte blocks ki corresponding to the plaintext encryption key Key1 are concatenated in the order of generation to obtain the encrypted ciphertext encryption key en_Key1, and the byte length of the ciphertext encryption key en_Key1 is also LenKey.

[0047] All the encrypted byte blocks ki corresponding to the plaintext encryption key Key2 are concatenated in the order of generation to obtain the encrypted ciphertext encryption key en_Key2. The byte length of the ciphertext encryption key en_Key2 is also LenKey.

[0048] Step S125, generate a CRC check code through the true random number Mask, byte length LenKey, ciphertext encryption key en_Key1, and ciphertext encryption key en_Key2, and store the CRC check code, true random number Mask, byte length LenKey, ciphertext encryption key en_Key1, ciphertext encryption key en_Key2 and key state identifier KeyState as a key storage unit.

[0049] A Crc check code is generated according to the true random number Mask, the byte length LenKey, the ciphertext encryption key en_Key1 and the ciphertext encryption key en_Key2, and the true random number Mask, the byte length LenKey, the ciphertext encryption key en_Key1, the ciphertext encryption key en_Key2 and the Crc check code are stored in the security chip SE220. After the above storage is completed, the key state identifier KeyState is stored in the security chip SE220 to mark that the storage of the group of key storage units is completed. Specifically, each group of key storage units is stored in the security chip SE220 according to the key storage unit format of the symmetric encryption algorithm (as shown in Table 1).

[0050] Step S130: If it exists, decrypt the ciphertext encryption key in the security chip SE220 to obtain the plaintext encryption key, and use the plaintext encryption key to encrypt the offline transaction information to form the offline transaction information ciphertext.

[0051] If there is a ciphertext encryption key in the security chip SE220, the security chip SE220 applies the true random number used in encryption to decrypt the ciphertext encryption key to obtain a plaintext encryption key, and then applies the decrypted plaintext encryption key to encrypt the offline transaction information M to form an offline transaction information ciphertext, which includes: the balance voucher list ciphertext BalVoucherC and the transaction flow list ciphertext TransBillC. Since the plaintext encryption key, the ciphertext encryption key, the offline transaction information, the encryption process, and the decryption process are all stored or occur in the security chip SE220, the present application can ensure the security of confidential data.

[0052] Specifically, Figure 4 As shown, step S130 includes the following sub-steps:

[0053] Step S131, verify the CRC code to determine whether the key storage unit has been tampered with.

[0054] Since the key state identifier KeyState has been used before to determine whether there is a ciphertext encryption key in the security chip SE220, when the ciphertext encryption keys en_Key1 and en_Key2 exist in the security chip SE220, the CRC check code is used to perform CRC check to prevent the group of key storage units containing the ciphertext encryption keys en_Key1 and en_Key2 stored in the security chip SE220 from being tampered with.

[0055] Step S132: If tampered with, terminate the operation.

[0056] If the key storage unit containing the ciphertext encryption keys en_Key1 and en_Key2 stored in the CRC verification security chip SE220 is tampered with, it means that the security chip SE220 may be attacked, all operations are terminated, the transaction fails, and all subsequent transactions are prohibited until the security risk is eliminated and normal use can be resumed.

[0057] Step S133: If there is no tampering, the ciphertext encryption keys en_Key1 and en_Key2 in the key storage unit are divided into b encryption byte blocks ki respectively, and each encryption byte block ki is XOR-operated with the true random number Mask in turn to generate a byte block Ki.

[0058] If a CRC check is performed to verify that the group of key storage units containing the ciphertext encryption keys en_Key1 and en_Key2 stored in the security chip SE220 has not been tampered with, the ciphertext encryption key en_Key1 in the security chip SE220 is divided into b encryption byte blocks ki, and each encryption byte block ki is XOR-ed with the true random number Mask in turn to generate a byte block Ki.

[0059] The ciphertext encryption key en_Key2 in the security chip SE220 is divided into b encryption byte blocks ki, and each encryption byte block ki is XOR-operated with the true random number Mask in turn to generate a byte block Ki.

[0060] Step S134, concatenate the byte blocks Ki in the order of generation to obtain the plaintext encryption keys Key1 and Key2.

[0061] The byte blocks Ki corresponding to the ciphertext encryption key en_Key1 are concatenated in the order of generation to obtain the plaintext encryption key Key1, and the byte length of the plaintext encryption key Key1 is LenKey; the byte blocks Ki corresponding to the ciphertext encryption key en_Key2 are concatenated in the order of generation to obtain the plaintext encryption key Key2, and the byte length of the plaintext encryption key Key2 is LenKey.

[0062] Step S135, encrypt the balance voucher list BalVoucherM with the plaintext encryption key Key1 to generate the balance voucher list ciphertext BalVoucherC, and encrypt the transaction flow list TransBillM with the plaintext encryption key Key2 to generate the transaction flow list ciphertext TransBillC.

[0063] After decrypting to obtain the plaintext encryption keys Key1 and Key2, use the plaintext encryption key Key1 to encrypt the balance voucher list BalVoucherM to generate the balance voucher list ciphertext BalVoucherC; use the plaintext encryption key Key2 to encrypt the transaction flow list TransBillM to generate the transaction flow list ciphertext TransBillC.

[0064] In addition, if the data length of the balance voucher list BalVoucherM is less than an integer multiple of the block size of the symmetric encryption algorithm used by the security chip SE220 to encrypt offline transaction information (for example, the block size of the national encryption SM4 is 16 bytes), the balance voucher list BalVoucherM is padded with '00' until its data length is an integer multiple of the block size of the symmetric encryption algorithm used by the security chip SE220 to encrypt offline transaction information; if the data length of the transaction flow list TransBillM is less than an integer multiple of the block size of the symmetric encryption algorithm used by the security chip SE220 to encrypt offline transaction information, the transaction flow list TransBillM is padded with '00' until its data length is an integer multiple of the block size of the symmetric encryption algorithm used by the security chip SE220 to encrypt offline transaction information.

[0065] Then, the plaintext encryption keys Key1 and Key2 are used to encrypt the balance voucher list BalVoucherM and the transaction list TransBillM respectively to generate the balance voucher list ciphertext BalVoucherC and the transaction list ciphertext TransBillC.

[0066] Step S140: Transmit the offline transaction information ciphertext to the MCU, and store the offline transaction information ciphertext in the MCU.

[0067] The security chip SE220 transmits the balance voucher list ciphertext BalVoucherC and the transaction flow list ciphertext TransBillC to MCU210 for storage through the SPI communication transmission protocol, thereby utilizing the large storage space of MCU210 to store a large amount of offline transaction information (balance voucher list, transaction flow list), thereby relaxing the transaction time limit and transaction frequency restrictions for offline payments. Moreover, the transaction information ciphertext is stored in MCU210, and even if it is stolen, the user's transaction information will not be leaked because there is no key. Such distributed storage further ensures information security.

[0068] In addition, the security chip SE220 also transmits the real length BalVoucherLen of the balance voucher list BalVoucherM and the real length TransBillLen of the transaction flow list TransBillM to MCU210 through the SPI communication transmission protocol, so as to be stored in MCU210.

[0069] Since each balance voucher list ciphertext BalVoucherC corresponds to the real length BalVoucherLen of a balance voucher list BalVoucherM, and each transaction flow list ciphertext TransBillC corresponds to the real length TransBillLen of a transaction flow list TransBillM, in subsequent synchronization operations, when the balance voucher list ciphertext BalVoucherC and the transaction flow list ciphertext TransBillC are transmitted from MCU210 to the security chip 220 for decryption, the decrypted balance voucher list BalVoucherM and transaction flow list TransBillM can be correctly verified based on the real length BalVoucherLen of the balance voucher list BalVoucherM and the real length TransBillLen of the transaction flow list TransBillM.

[0070] Specifically, in MCU210, the real length BalVoucherLen of the balance voucher list BalVoucherM and the ciphertext BalVoucherC of the balance voucher list are stored according to the storage unit format of Table 2, and the real length TransBillLen of the transaction flow list TransBillM and the ciphertext TransBillC of the transaction flow list are stored according to the storage unit format of Table 3.

[0071] Table 2 MCU balance voucher list ciphertext storage unit format

[0072] Field Definition Length (bytes) describe Crc 2 CRC verification to prevent data tampering TransactionNum 2 Total number of transactions BalVoucherLen1 2 The actual length of the balance voucher generated by the first transaction BalVoucherC1 BalVoucherLen1' The balance certificate ciphertext generated by the first transaction BalVoucherLen2 2 The actual length of the balance voucher generated by the second transaction BalVoucherC2 BalVoucherLen2' The balance certificate ciphertext generated by the second transaction ...... ...... ......

[0073] BalVoucherLenx'=(BalVoucherLenx+(blocksize-1)) / blocksize*blocksize

[0074] Among them, blocksize is the block size of the symmetric encryption algorithm used by the security chip SE220 to encrypt offline transaction information. Since the data length of the balance voucher list BalVoucherM may be less than an integer multiple of the block size of the symmetric encryption algorithm used by the security chip SE220 to encrypt offline transaction information, it is necessary to fill the balance voucher list BalVoucherM with '00'. Therefore, the length of the balance voucher list ciphertext BalVoucherC and the actual length BalVoucherLen of the balance voucher list BalVoucherM may be different.

[0075] The total number of transactions TransactionNum is also recorded in MCU210, and each time a balance voucher list ciphertext BalVoucherC is added, the total number of transactions TransactionNum increases by 1. The total number of transactions TransactionNum can facilitate MCU210 to know the number of remaining balance voucher list ciphertext BalVoucherC in subsequent synchronization operations.

[0076] In addition, in response to the balance voucher list ciphertext BalVoucherC being updated in MCU210, the CRC check code is calculated through all the balance voucher list ciphertext BalVoucherC, and the CRC check code is recorded in MCU210, and before the next update of the balance voucher list ciphertext BalVoucherC, the data integrity and accuracy are verified by verifying the CRC check code. If the verification fails, it means that the stored balance voucher list ciphertext BalVoucherC and other data have been tampered with, the current behavior is stopped, and the transaction fails; if the verification passes, it means that the stored balance voucher list ciphertext BalVoucherC and other data have not been tampered with, the new balance voucher list ciphertext BalVoucherC is added, and the new CRC check code is calculated, and then the CRC check code is updated, so as to ensure the integrity and accuracy of the transaction data ciphertext.

[0077] Table 3 MCU transaction list ciphertext storage unit format

[0078] Field Definition Length (bytes) describe Crc 2 CRC verification to prevent data tampering TransactionNum 2 Total number of transactions TransBillLen1 2 The actual length of the first transaction flow TransBillC1 TransBillLen1' First transaction ciphertext TransBillLen2 2 The actual length of the second transaction flow TransBillC2 TransBillLen2' Second transaction ciphertext ...... ...... ......

[0079] TransBillLenx'=(TransBillLenx+(blocksize-1)) / blocksize*blocksize

[0080] Among them, blocksize is the block size of the symmetric encryption algorithm used by the security chip SE220 to encrypt offline transaction information. Since the data length of the transaction list TransBillM may be less than an integer multiple of the block size of the symmetric encryption algorithm used by the security chip SE220 to encrypt offline transaction information, it is necessary to fill the transaction list TransBillM with '00'. Therefore, the length of the transaction list ciphertext TransBillC and the actual length TransBillLen of the transaction list TransBillM may be different.

[0081] The total number of transactions TransactionNum is also recorded in MCU210, and each time a transaction list ciphertext TransBillC is added, the total number of transactions TransactionNum increases by 1. The total number of transactions TransactionNum can facilitate MCU210 to know the number of remaining transaction list ciphertexts TransBillC in subsequent synchronization operations.

[0082] In addition, in response to the update of the transaction list ciphertext TransBillC in MCU210, the CRC check code is calculated through all the transaction list ciphertext TransBillC, and the CRC check code is recorded in MCU210, and before the next update of the transaction list ciphertext TransBillC, the data integrity and accuracy are verified by verifying the CRC check code. If the verification fails, it means that the stored transaction list ciphertext TransBillC and other data have been tampered with, the current behavior is stopped, and the transaction fails; if the verification passes, it means that the stored transaction list ciphertext TransBillC and other data have not been tampered with, the new transaction list ciphertext TransBillC is added, and the new CRC check code is calculated, and then the CRC check code is updated to ensure the integrity and accuracy of the transaction data ciphertext.

[0083] Embodiment 2

[0084] like Figure 5 As shown, the present application provides a method for synchronously uploading dual offline information of a digital currency hard wallet, comprising the following steps:

[0085] Step S505: The wallet APP sends a synchronization operation instruction to the security chip SE.

[0086] like Figure 2As shown, the digital currency hard wallet 200 includes: a digital currency hard wallet body 230, an MCU210 and a security chip SE220; the MCU210 and the security chip SE220 are located inside the digital currency hard wallet body 230, and the digital currency hard wallet body 230 can be a terminal such as a card, a bracelet, or a keychain. Among them, the security chip SE220 has software and hardware security support and can be used to store confidential data, but the storage space is relatively small; the storage space of MCU210 is large, but it cannot be used to store confidential data. In this application, the MCU210 with a large storage space is used to store a large amount of offline transaction information (balance voucher list, transaction flow list), so that the transaction time limit and transaction number restrictions of offline payment can be relaxed, but the security of offline transaction information stored on MCU210 needs to be guaranteed.

[0087] The wallet APP runs on electronic devices such as mobile phones and watches. In response to the electronic device running the wallet APP connecting to the network, the wallet APP sends a synchronization operation instruction to the security chip SE220 to start the synchronization operation of offline transaction information to the institution background. The synchronization operation is the substantive transaction link. Before starting the synchronization operation, the institution background will initialize the digital currency hard wallet. During the initialization stage, it is used to complete the authentication of the hard wallet by the institution background, and does not involve the processing of offline transaction information stored in MCU210.

[0088] Step S510: In response to receiving the synchronization operation instruction, the security chip SE sends basic response information + status code 9200 to the wallet APP.

[0089] In response to receiving the synchronization operation instruction sent by the wallet APP, the security chip SE220 will first send basic response information to the wallet APP according to the requirements of the synchronization operation response message format. As shown in Table 4, the basic response information is composed of the data hardware wallet association code, parent wallet ID, hardware wallet ID and transaction index before the offline transaction information Translnfo.

[0090] Table 4 Synchronous operation response message format

[0091]

[0092] Since the synchronous operation response message contains offline transaction information, it is super-long data, and the specification stipulates the reception of super-long information by the wallet APP. If the response data length of an APDU instruction (Application Protocol Data Unit) exceeds 255 bytes, the instruction returns a "9200" status code to indicate that the wallet APP still has data to be received. In this way, the wallet APP obtains the super-long data by continuously sending DC / EP (Digital Currency Electronic Payment) response commands until the instruction returns a "9000" status code.

[0093] Based on this, the present application can process offline transaction information in blocks, decrypt a block of ciphertext block data of offline transaction information into plain text, send it to the wallet APP, and then receive the next block of ciphertext block data of offline transaction information from MCU210 and decrypt it into plain text, and then send it to the wallet APP until all offline transaction information is processed.

[0094] Step S515: The security chip SE decrypts the ciphertext encryption key stored therein to obtain a plaintext encryption key.

[0095] The security chip SE220 stores a ciphertext encryption key. After the security chip SE220 receives the synchronization operation instruction, the security chip SE220 decrypts the ciphertext encryption key to obtain a plaintext encryption key.

[0096] When encrypting the balance voucher list BalVoucherM of offline transaction information, the plaintext encryption key Key1 is used, and the generated balance voucher list ciphertext BalVoucherC is generated. When encrypting the transaction flow list TransBillM of offline transaction information, the plaintext encryption key Key2 is used, and the generated transaction flow list ciphertext TransBillC is generated. Therefore, the security chip SE220 stores the ciphertext encryption keys en_Key1 and en_Key2 corresponding to the plaintext encryption keys Key1 and Key2. Therefore, in the synchronous operation, the ciphertext encryption keys en_Key1 and en_Key2 are decrypted to obtain the plaintext encryption keys Key1 and Key2.

[0097] In the present application, all offline transaction information between two synchronizations of offline transaction information is encrypted using the same set of plaintext encryption keys Key1 and Key2. Therefore, in the process of synchronizing offline transaction information once, the decryption operation of the ciphertext encryption keys en_Key1 and en_Key2 can be performed only once.

[0098] Step S520, in response to receiving the basic response information and status code 9200, the wallet APP sends the basic response information to the institution's backend, and sends a DC / EP response command to the security chip SE based on the status code 9200.

[0099] After the wallet APP receives the basic response information and status code 9200 sent by the security chip SE220, the wallet APP will send the basic response information to the institution's backend for processing. At the same time, the wallet APP will send a DC / EP response command to the security chip SE220 to request subsequent offline transaction information.

[0100] Step S525: In response to receiving the DC / EP response command, the security chip SE requests the MCU for the ciphertext block data of the offline transaction information ciphertext.

[0101] MCU210 can divide the offline transaction information ciphertext (balance voucher list ciphertext BalVoucherC and transaction flow list ciphertext TransBillC) into multiple ciphertext block data in sequence according to the total number of offline transactions TransactionNum. For example, the offline transaction information ciphertext can be divided into ciphertext block data C1, C2...Cn with 128 bytes (which can be changed according to the situation).

[0102] Of course, the security chip SE220 can also obtain the balance voucher list ciphertext BalVoucherC and the transaction flow list ciphertext TransBillC at one time without dividing the balance voucher list ciphertext BalVoucherC and the transaction flow list ciphertext TransBillC into blocks, so as to reduce the number of communications between the security chip SE220 and MCU210, as long as the length of the balance voucher list ciphertext BalVoucherC and the transaction flow list ciphertext TransBillC is within the tolerance of the security chip SE220.

[0103] After the security chip SE220 receives the first DC / EP response command sent by the wallet APP, it will request the first ciphertext block data C1 of the offline transaction information from MCU210, and will subsequently request other ciphertext block data of the offline transaction information from MCU210 according to the DC / EP response command.

[0104] Step S530: The MCU sends the ciphertext block data of the offline transaction information ciphertext to the security chip SE.

[0105] After MCU210 receives the request from the security chip SE220 for the ciphertext block data of the offline transaction information ciphertext, it verifies the data integrity and accuracy of the offline transaction information ciphertext stored in MCU210 (the balance voucher list ciphertext BalVoucherC and the transaction flow list ciphertext TransBillC) by verifying the CRC check code. If the verification fails, it means that the stored offline transaction information ciphertext has been tampered with and the synchronization operation is stopped; if the verification passes, it means that the stored offline transaction information ciphertext has not been tampered with and the subsequent operation continues.

[0106] After the CRC verification code is verified, MCU210 sends the first ciphertext block data C1 of the offline transaction information ciphertext to the security chip SE220 according to the first DC / EP response command, and then MCU210 sends the second ciphertext block data C2 of the offline transaction information ciphertext to the security chip SE220 according to the second DC / EP response command, and sends the subsequent ciphertext block data in sequence.

[0107] Step S535: The security chip SE uses the plaintext encryption key to decrypt the ciphertext block data of the offline transaction information ciphertext, obtains the block data of the offline transaction information, and sends the block data of the offline transaction information + status code 9200 to the wallet APP.

[0108] After the security chip SE220 receives the ciphertext block data C1, C2... of the offline transaction information ciphertext, the security chip SE220 decrypts the ciphertext block data C1, C2... according to the plaintext encryption keys Key1 and Key2 obtained by decryption to obtain the block data TransInfo1, TransInfo2... of the offline transaction information.

[0109] In this process, the security chip SE220 determines whether the ciphertext block data of the offline transaction information ciphertext is the ciphertext block data of the balance voucher list ciphertext BalVoucherC or the ciphertext block data of the transaction flow list ciphertext TransBillC based on the total number of transactions. If it is the ciphertext block data of the balance voucher list ciphertext BalVoucherC, it is decrypted using the plaintext encryption key Key1; if it is the ciphertext block data of the transaction flow list ciphertext TransBillC, it is decrypted using the ciphertext encryption key Key2 to decrypt the plaintext.

[0110] Furthermore, if there is still data that has not been sent, that is, the block data TransInfo1, TransInfo2, ... of the offline transaction information is sent, the security chip SE220 also returns a "9200" status code to the wallet APP, indicating that the wallet APP still has data to be received.

[0111] Step S540, in response to receiving the block data and status code 9200 of the offline transaction information, the wallet APP sends the block data of the offline transaction information to the institution background, and sends a DC / EP response command to the security chip SE according to the status code 9200.

[0112] After the wallet APP receives the block data TransInfo1, TransInfo2... and status code 9200 of the offline transaction information sent by the security chip SE220, the wallet APP will send the block data TransInfo1, TransInfo2... of the offline transaction information to the institution's backend for processing. At the same time, the wallet APP will send a DC / EP response command to the security chip SE220 based on the status code 9200 to carry out subsequent offline transaction information.

[0113] Step S545: In response to receiving the DC / EP response command, the security chip SE requests the MCU for the ciphertext block data of the offline transaction information ciphertext.

[0114] After the security chip SE220 receives the next DC / EP response command sent by the wallet APP, it will request the next ciphertext block data of the offline transaction information from MCU210. Until the security chip SE220 receives the nth DC / EP response command sent by the wallet APP, it will request the nth ciphertext block data Cn of the offline transaction information from MCU210.

[0115] Step S550: The MCU sends the last ciphertext block data of the offline transaction information ciphertext to the security chip SE along with an end mark.

[0116] Until MCU210 receives the request from security chip SE220 for the nth ciphertext block data Cn of offline transaction information, it sends the nth ciphertext block data Cn of the offline transaction information ciphertext to security chip SE220 according to the nth DC / EP response command, so that MCU210 passes the ciphertext block data C1, C2....Cn to security chip SE220 in sequence.

[0117] After all the offline transaction information ciphertexts are processed, MCU210 also adds an end mark to the last ciphertext block data Cn, thereby notifying the security chip SE220 that MCU210 has transmitted all the offline transaction information ciphertexts.

[0118] Step S555: The security chip SE uses the plaintext encryption key to decrypt the last block of ciphertext data of the offline transaction information ciphertext, obtains the last block of data of the offline transaction information, and sends the last block of data of the offline transaction information and MAC3+status code 9000 to the wallet APP, and updates the transaction status to pending confirmation.

[0119] After the security chip SE220 receives the last ciphertext block data Cn of the offline transaction information ciphertext, the security chip SE220 decrypts the ciphertext block data Cn according to the plaintext encryption keys Key1 and Key2 obtained by decryption to obtain the last block data TransInfon of the offline transaction information.

[0120] In addition, the security chip SE220 detects that the ciphertext block data Cn of the offline transaction information ciphertext is accompanied by an end mark. After obtaining the block data TransInfon of the offline transaction information, it also calculates MAC3 (message authentication code) and sends both the block data TransInfon and MAC3 of the offline transaction information to the wallet APP, so that the institution background can verify through MAC3 to ensure the authenticity, integrity and non-repudiation of the transaction.

[0121] In addition, the security chip SE220 will also determine whether it contains padding data based on the actual length BalVoucherLen of the recorded balance voucher list BalVoucherM and the actual length TransBillLen of the transaction flow list TransBillM. If there is padding data, the padding data will be cleared and then responded to the wallet APP.

[0122] Furthermore, if there is no data to be sent, that is, what is sent is the block data TransInfon and MAC3 of the offline transaction information, the security chip SE220 also returns a "9000" status code to the wallet APP, indicating that the wallet APP has no data to be received.

[0123] Step S560, in response to receiving the last block data and MAC3 of the offline transaction information and the status code 9000, the wallet APP sends the last block data and MAC3 of the offline transaction information to the institution background, and no longer sends a DC / EP response command to the security chip SE based on the status code 9000.

[0124] After the wallet APP receives the block data TransInfon and MAC3 of the offline transaction information and the status code 9000 sent by the security chip SE220, the wallet APP will send the block data TransInfon and MAC3 of the offline transaction information to the institution's backend for processing. At the same time, since the wallet APP received the status code 9000, it means that there is no data to be sent in MCU210. Therefore, the wallet APP does not need to send a DC / EP response command to the security chip SE220, but waits for the response from the institution's backend.

[0125] In addition, since the block data TransInfon of offline transaction information is also spliced ​​with MAC3, after the wallet APP sends the block data TransInfon and MAC3 of offline transaction information to the institution's backend, the institution's backend will first verify MAC3 to ensure the authenticity, integrity and non-repudiation of the transaction.

[0126] If the verification fails, the synchronization operation is invalid and the synchronization operation is stopped; if the verification passes, the synchronization operation is valid, and the block data TransInfo1, TransInfo2...TransInfon of all offline transaction information received are processed to generate a new currency string DC, and the new currency string DC is sent to the wallet APP, and the transaction status is updated to pending confirmation.

[0127] Step S565, in response to receiving the new coin string DC obtained by the institution's backend based on the block data processing of all offline transaction information, the wallet APP sends a synchronization completion instruction to the security chip SE to issue the new coin string DC.

[0128] After the wallet APP receives the new currency string DC sent by the institution's backend, the wallet APP sends a synchronization completion instruction to the security chip SE220 to send the new currency string DC, and instructs the security chip SE220 to complete subsequent operations according to the synchronization completion instruction.

[0129] Step S570: The security chip SE stores the new coin string DC, updates the transaction status to completion, deletes the ciphertext encryption key, and requests the MCU to delete the offline transaction information.

[0130] After the security chip SE220 receives the synchronization completion instruction sent by the wallet APP, the security chip SE220 stores the new coin string DC inside the security chip SE220 to utilize the security of the security chip SE220. In addition, the security chip SE220 also updates the transaction status to completion, and deletes the ciphertext encryption keys en_Key1 and en_Key2 stored in the security chip SE220, that is, deletes all data in Table 1. In addition, the security chip SE220 also sends a request to delete offline transaction information to MCU210 to instruct MCU210 to delete the offline transaction information stored therein.

[0131] Step S575: In response to receiving the request to delete the offline transaction information, the MCU deletes the offline transaction information stored therein.

[0132] After receiving the request to delete offline transaction information sent by security chip SE220, MCU210 deletes the offline transaction information (balance voucher list ciphertext BalVoucherC and transaction flow list ciphertext TransBillC) stored in MCU210, that is, deletes all data in Table 2 and Table 3.

[0133] Step S580: In response to the security chip SE updating the transaction status to completion, the security chip SE sends synchronization update completion response data to the wallet APP.

[0134] After the security chip SE220 updates the transaction status to completion, the security chip SE220 sends synchronization update completion response data to the wallet APP to indicate that the synchronization update is completed in the security chip SE220.

[0135] Step S585: The wallet APP transmits the synchronization update completion response data to the institution's backend.

[0136] After the wallet APP receives the synchronization update completion response data sent by the security chip SE220, it passes the synchronization update completion response data to the institution background. The institution background updates the transaction status to completion according to the synchronization update completion response data, and the transaction is completed.

[0137] Embodiment 3

[0138] like Figure 2 As shown, the present application provides a digital currency hard wallet 200, including: a digital currency hard wallet body 230, an MCU210, a security chip SE220 and a wallet APP; the MCU210 and the security chip SE220 are located inside the digital currency hard wallet body 230, and the wallet APP runs on the digital currency hard wallet body 230; and the MCU210, the security chip SE220 and the wallet APP execute the methods of embodiments one and two.

[0139] This application adopts a distributed storage method, stores the ciphertext encryption key on the security chip SE, and stores the offline transaction information ciphertext on the MCU. The offline transaction information generated by each offline transaction is encrypted by the plaintext encryption key and transmitted from the security chip SE to the MCU for storage in a certain format. After connecting to the network, the MCU transmits all offline transaction information in blocks to the security chip SE in sequence. The security chip SE decrypts the received data blocks using the plaintext encryption key to obtain the plaintext transaction information, and transmits the plaintext transaction information to the institution's backend. This application can store the massive amount of offline transaction information generated by digital currency payments, and ensure the security of offline transaction information storage.

[0140] It will be apparent to those skilled in the art that the invention is not limited to the details of the exemplary embodiments described above and that the invention can be implemented in other specific forms without departing from the spirit or essential features of the invention. Therefore, the embodiments should be considered exemplary and non-limiting in all respects, and the scope of the invention is defined by the appended claims rather than the foregoing description, and it is intended that all variations falling within the meaning and scope of the equivalent elements of the claims be included in the invention. Any reference numeral in a claim should not be considered as limiting the claim to which it relates.

[0141] In addition, it should be understood that although the present specification is described according to implementation modes, not every implementation mode contains only one independent technical solution. This description of the specification is only for the sake of clarity. Those skilled in the art should regard the specification as a whole. The technical solutions in each embodiment may also be appropriately combined to form other implementation modes that can be understood by those skilled in the art.

Claims

1. A method for securely storing dual offline information of a digital currency hard wallet, characterized in that: The steps include: Step S110, in response to generating offline transaction information, determining whether there is a ciphertext encryption key in the security chip SE; Step S120: If it does not exist, randomly generate a plaintext encryption key, encrypt the plaintext encryption key to form a ciphertext encryption key, and store the ciphertext encryption key in the security chip SE; Step S130: If it exists, decrypt the ciphertext encryption key in the security chip SE to obtain the plaintext encryption key, and use the plaintext encryption key to encrypt the offline transaction information to form the offline transaction information ciphertext; Step S140: Transmit the offline transaction information ciphertext to the MCU, and store the offline transaction information ciphertext in the MCU.

2. The method for securely storing dual offline information of a digital currency hard wallet according to claim 1, characterized in that: Step S120 includes the following sub-steps: Step S121, generate a true random number Mask of m bytes, and randomly generate plaintext encryption keys Key1 and Key2 with a byte length of LenKey; Step S122, divide the plaintext encryption keys Key1 and Key2 into m-byte blocks of b=(LenKey+m-1) / m bytes; Step S123, performing an XOR operation on each byte block Ki and the true random number Mask to generate an encrypted byte block ki; Step S124, concatenate the encrypted byte blocks ki in the order of generation to obtain ciphertext encryption keys en_Key1 and en_Key2 with a byte length of LenKey; Step S125, generate a CRC check code through the true random number Mask, byte length LenKey, ciphertext encryption key en_Key1, and ciphertext encryption key en_Key2, and store the CRC check code, true random number Mask, byte length LenKey, ciphertext encryption key en_Key1, ciphertext encryption key en_Key2 and key state identifier KeyState as a key storage unit.

3. The method for securely storing dual offline information of a digital currency hard wallet according to claim 2, characterized in that: Offline transaction information includes: balance voucher list BalVoucherM and transaction flow list TransBillM.

4. The method for securely storing dual offline information of a digital currency hard wallet according to claim 3 is characterized in that: Step S130 includes the following sub-steps: Step S131, verifying the CRC check code to determine whether the key storage unit has been tampered with; Step S132: If tampered, terminate the operation; Step S133: If no tampering has occurred, the ciphertext encryption keys en_Key1 and en_Key2 in the key storage unit are divided into b encryption byte blocks ki, and each encryption byte block ki is subjected to an XOR operation with a true random number Mask to generate a byte block Ki; Step S134, concatenate the byte blocks Ki in the order of generation to obtain the plaintext encryption keys Key1 and Key2; Step S135, encrypt the balance voucher list BalVoucherM with the plaintext encryption key Key1 to generate the balance voucher list ciphertext BalVoucherC, and encrypt the transaction flow list TransBillM with the plaintext encryption key Key2 to generate the transaction flow list ciphertext TransBillC.

5. The method for securely storing dual offline information of a digital currency hard wallet according to claim 4, characterized in that: If the data length of the balance voucher list BalVoucherM is less than an integer multiple of the block size of the symmetric encryption algorithm used by the security chip SE to encrypt offline transaction information, the balance voucher list BalVoucherM is padded with '00' until its data length is an integer multiple of the block size of the symmetric encryption algorithm used by the security chip SE to encrypt offline transaction information; If the data length of the transaction list TransBillM is less than an integer multiple of the block size of the symmetric encryption algorithm used by the security chip SE to encrypt offline transaction information, the transaction list TransBillM is padded with '00' until its data length is an integer multiple of the block size of the symmetric encryption algorithm used by the security chip SE to encrypt offline transaction information; Then use the plaintext encryption keys Key1 and Key2 to encrypt the balance voucher list BalVoucherM and the transaction list TransBillM respectively to generate the balance voucher list ciphertext BalVoucherC and the transaction list ciphertext TransBillC.

6. The method for securely storing dual offline information of a digital currency hard wallet according to claim 4, characterized in that: The balance voucher list ciphertext BalVoucherC and the transaction flow list ciphertext TransBillC are both transmitted to the MCU for storage; The real length BalVoucherLen of the balance voucher list BalVoucherM and the real length TransBillLen of the transaction flow list TransBillM are transmitted to the MCU for storage.

7. A method for synchronously uploading dual offline information of a digital currency hard wallet, characterized in that: The steps include: Step S505: The wallet APP sends a synchronization operation instruction to the security chip SE; Step S510: In response to receiving the synchronization operation instruction, the security chip SE sends basic response information + status code 9200 to the wallet APP; Step S515: The security chip SE decrypts the ciphertext encryption key stored therein to obtain a plaintext encryption key; Step S520: In response to receiving the basic response information and status code 9200, the wallet APP sends the basic response information to the institution backend, and sends a DC / EP response command to the security chip SE according to the status code 9200; Step S525: In response to receiving the DC / EP response command, the security chip SE requests the MCU for the ciphertext block data of the offline transaction information ciphertext; Step S530, the MCU sends the ciphertext block data of the offline transaction information ciphertext to the security chip SE; Step S535: The security chip SE uses the plaintext encryption key to decrypt the ciphertext block data of the offline transaction information ciphertext, obtains the block data of the offline transaction information, and sends the block data of the offline transaction information + status code 9200 to the wallet APP; Step S540: In response to receiving the block data of the offline transaction information and the status code 9200, the wallet APP sends the block data of the offline transaction information to the institution background, and sends a DC / EP response command to the security chip SE according to the status code 9200; Step S545: In response to receiving the DC / EP response command, the security chip SE requests the MCU for the ciphertext block data of the offline transaction information ciphertext; Step S550: The MCU sends the last ciphertext block data of the offline transaction information ciphertext to the security chip SE along with an end mark; Step S555: The security chip SE uses the plaintext encryption key to decrypt the last block of ciphertext data of the offline transaction information ciphertext, obtains the last block of data of the offline transaction information, and sends the last block of data of the offline transaction information and MAC3+status code 9000 to the wallet APP, and updates the transaction status to pending confirmation; Step S560: In response to receiving the last block data and MAC3 of the offline transaction information and the status code 9000, the wallet APP sends the last block data and MAC3 of the offline transaction information to the institution background, and no longer sends a DC / EP response command to the security chip SE according to the status code 9000; Step S565: In response to receiving the new coin string DC obtained by the institution backend based on the block data processing of all offline transaction information, the wallet APP sends a synchronization completion instruction to the security chip SE to issue the new coin string DC; Step S570: The security chip SE stores the new coin string DC, updates the transaction status to completed, deletes the ciphertext encryption key, and requests the MCU to delete the offline transaction information; Step S575: In response to receiving the request to delete the offline transaction information, the MCU deletes the offline transaction information stored therein; Step S580: In response to the security chip SE updating the transaction status to completion, the security chip SE sends synchronization update completion response data to the wallet APP; Step S585: The wallet APP transmits the synchronization update completion response data to the institution's backend.

8. The method for synchronously uploading dual offline information of a digital currency hard wallet according to claim 7, characterized in that: The MCU divides the offline transaction information ciphertext into multiple ciphertext block data in sequence according to the total offline transaction number TransactionNum.

9. The method for synchronously uploading dual offline information of a digital currency hard wallet according to claim 8, characterized in that: Offline transaction information includes: balance voucher list BalVoucherM and transaction list TransBillM. The security chip SE will determine whether it contains padding data based on the actual length BalVoucherLen of the recorded balance voucher list BalVoucherM and the actual length TransBillLen of the transaction list TransBillM. If there is padding data, the padding data will be cleared and then responded to the wallet APP.

10. A digital currency hard wallet system, characterized in that: include: Digital currency hardware wallet and wallet APP; A digital currency hard wallet, comprising: a digital currency hard wallet body, an MCU and a security chip SE, wherein the MCU and the security chip SE are located inside the digital currency hard wallet body; The wallet APP runs on the terminal; and the MCU, the security chip SE and the wallet APP execute the method of any one of claims 1-9.

Images