An offline billing method and apparatus

Abstract

This specification provides an offline bill generation method and apparatus. The method includes: a terminal device comprising a Trusted Execution Environment (TEE) and a secure element based on encrypted hardware; when the terminal device detects a transaction by a target account in an offline scenario, obtaining basic transaction information and the target account's identity information in the TEE; sending the basic transaction information and the identity information to the secure element; in the secure element, signing the basic transaction information and the identity information using a stored first private key to obtain a first signature; and in the TEE, combining the basic transaction information, the identity information, and the first signature to generate an offline bill corresponding to the transaction and storing the offline bill.

Description

[0001] This application is a divisional application of the invention patent application filed on July 22, 2021, with application number 2021108317560, entitled "An Offline Bill Generation Method and Apparatus". Technical Field

[0002] This specification relates to the field of electronic payment security technology, and in particular to an offline bill generation method and apparatus. Background Technology

[0003] Offline payments are gaining increasing attention from various institutions. Offline payments, which can be made without an internet connection, include single offline payments and dual offline payments. Single offline payments refer to either the payee or the payer being offline, while dual offline payments refer to both the payee and the payer being offline. Unlike online electronic payments, where all invoices are generated and stored directly on the server in real time, offline payment invoices are first generated locally on the offline party's device and then synchronized to the corresponding server only when the device is connected to the internet. In other words, before the offline party's device is connected to the internet, the generated invoice must be stored locally on that device. Consequently, the secure management of invoices on the offline party's device before it becomes connected to the internet requires particular attention.

[0004] Currently, for offline payments, a pure SE (Secure Element) solution is generally used to generate and manage offline bills. That is, the bill is generated and saved in the SE of the offline party's device, and subsequent bill management is based on the device's SE.

[0005] In the above solution, the SE has limited storage space and cannot store too many offline bills. When there are many offline transactions on the device, the storage, management and synchronization of offline bills will be limited. Summary of the Invention

[0006] This specification provides an offline bill generation method and apparatus, which achieves better storage, management and synchronization of offline bills through the technical solutions of the embodiments of this specification.

[0007] In a first aspect, this specification provides an offline bill generation method applied to a terminal device, the terminal device including a Trusted Execution Environment (TEE) and a security element based on cryptographic hardware, the method comprising:

[0008] When a transaction is detected in an offline scenario, the basic transaction information corresponding to the transaction and the identity information of the target account are obtained in the TEE.

[0009] The basic transaction information and the identity information are sent to the secure element;

[0010] In the secure element, the basic transaction information and the identity information are signed using the stored first private key to obtain a first signature;

[0011] In the TEE, the basic transaction information, the identity information, and the first signature are combined to generate an offline bill corresponding to the transaction, and the offline bill is stored.

[0012] In one implementation, the terminal device further includes a general execution environment (REE).

[0013] The basic transaction information corresponding to the transaction and the identity information of the target account are obtained in the TEE, including:

[0014] The basic transaction information is obtained from the payment-related applications running in the REE;

[0015] The identity information is obtained from the secure storage area of ​​the TEE.

[0016] In one implementation, the basic transaction information includes at least one of the following:

[0017] The transaction amount, transaction ID, transaction type, transaction currency, transaction time, target account nickname, and the nickname of another account that transacted with the target account.

[0018] In one implementation, the identity information includes at least one of the following:

[0019] The target account ID, the operating organization ID to which the target account belongs, and the main account ID to which the target account belongs.

[0020] In one implementation, after obtaining the first signature, the method further includes:

[0021] In the secure element, the target account's account balance is updated based on the underlying transaction information after the transaction occurs.

[0022] In one implementation, the basic transaction information includes the transaction amount and transaction type;

[0023] In the secure element, the basic transaction information and the identity information are signed using the stored first private key to obtain a first signature, including:

[0024] When the transaction type is a payment type, the security element determines whether the stored account balance is not less than the transaction amount.

[0025] If the determination result is yes, then the stored first private key is used to sign the basic transaction information and the identity information to obtain the first signature.

[0026] One implementation also includes:

[0027] If the account balance is determined to be less than the transaction amount, an insufficient balance message will be output.

[0028] One implementation also includes:

[0029] When the terminal device is detected to be connected to the network, the offline bill is synchronized to the server via the TEE.

[0030] In one implementation, the step of synchronizing the offline bill to the server via the TEE when the terminal device is detected to be connected to the network includes:

[0031] If the terminal is detected to be connected to the network, a bill synchronization prompt message will be displayed;

[0032] When a selection operation is detected for the bill synchronization prompt information, the offline bill is synchronized to the server via the TEE.

[0033] One implementation also includes:

[0034] In the TEE, the offline bill is encrypted using a randomly generated symmetric key to obtain the encrypted offline bill;

[0035] In the TEE, the symmetric key is encrypted using a pre-set server public key;

[0036] Based on the encrypted symmetric key and the encrypted offline bill, an offline bill synchronization message is generated;

[0037] The process of synchronizing the offline bill to the server via the TEE includes:

[0038] The offline bill synchronization message is sent to the server via the TEE, so that the server can use the server private key, the first public key corresponding to the first private key, and the offline bill synchronization message to determine the latest balance of the target account.

[0039] In a second aspect of this specification, an offline bill generation apparatus is provided, applied to a terminal device, the terminal device including a Trusted Execution Environment (TEE) and a security element based on cryptographic hardware, the apparatus comprising:

[0040] The information acquisition module is configured to obtain basic transaction information corresponding to the transaction and the identity information of the target account in the TEE when a transaction is detected to occur in an offline scenario.

[0041] The information sending module is configured to send the basic transaction information and the identity information to the security element;

[0042] The signature module is configured to use a stored first private key to sign the basic transaction information and the identity information in the secure element to obtain a first signature;

[0043] A storage module is configured to combine the basic transaction information, the identity information, and the first signature in the TEE to generate an offline bill corresponding to the transaction and store the offline bill.

[0044] In one implementation, the terminal device further includes a general execution environment (REE).

[0045] The information acquisition module is specifically configured to obtain the basic transaction information from the payment-related application running in the REE;

[0046] The identity information is obtained from the secure storage area of ​​the TEE.

[0047] In one implementation, the basic transaction information includes at least one of the following:

[0048] The transaction amount, transaction ID, transaction type, transaction currency, transaction time, target account nickname, and the nickname of another account that transacted with the target account.

[0049] In one implementation, the identity information includes at least one of the following:

[0050] The target account ID, the operating organization ID to which the target account belongs, and the main account ID to which the target account belongs.

[0051] In one implementation, the apparatus further includes:

[0052] The update module is configured to, after obtaining the first signature, update the target account's account balance in the secure element based on the underlying transaction information after the transaction occurs.

[0053] In one implementation, the basic transaction information includes the transaction amount and transaction type;

[0054] The signature module includes:

[0055] The judgment unit is configured to, when the transaction type is a payment type, determine in the security element whether the stored account balance is not less than the transaction amount;

[0056] The signature unit is configured to, if the determination result is yes, use the stored first private key to sign the basic transaction information and the identity information to obtain the first signature.

[0057] In one implementation, the signature module further includes:

[0058] The prompt message output unit is configured to output a prompt message indicating insufficient balance if it is determined that the account balance is less than the transaction amount.

[0059] One implementation also includes:

[0060] The synchronization module is configured to synchronize the offline bill to the server via the TEE when the terminal device is detected to be connected to the network.

[0061] In one implementation, the synchronization module is specifically configured to display a bill synchronization prompt when the terminal is detected to be connected to the network;

[0062] When a selection operation is detected for the bill synchronization prompt information, the offline bill is synchronized to the server via the TEE.

[0063] One implementation also includes:

[0064] The first encryption module is configured to encrypt the offline bill using a randomly generated symmetric key in the TEE to obtain the encrypted offline bill.

[0065] The second encryption module is configured to encrypt the symmetric key using a preset server public key in the TEE;

[0066] The message generation module is configured to generate an offline bill synchronization message based on the encrypted symmetric key and the encrypted offline bill.

[0067] The synchronization module is specifically configured to send the offline bill synchronization message to the server through the TEE, so that the server can use the server private key, the first public key corresponding to the first private key, and the offline bill synchronization message to determine the latest balance of the target account.

[0068] In a third aspect of this specification, a computer-readable storage medium is provided having a computer program stored thereon that, when executed in a computer, causes the computer to perform the offline bill generation method provided in one or more embodiments of this specification.

[0069] In a fourth aspect of this specification, a computing device is provided, including a memory and a processor, wherein the memory stores executable code, and the processor executes the executable code to implement the offline billing generation method provided in one or more embodiments of this specification.

[0070] According to the embodiments of this specification, an offline bill generation method and apparatus are provided. The terminal device pre-configures data environments with different security levels, including a Trusted Execution Environment (TEE) and a secure element based on cryptographic hardware. A first private key with the required high security level is stored in the secure element, and signing is performed therein. The assembly and generation of offline bills are performed within the TEE, which has a higher security level, faster data processing speed, and relatively larger storage space (compared to the secure element). This utilizes data environments with different security levels to achieve the assembly, signing, and generation of offline bills, fully leveraging the capabilities and characteristics of each security level data environment to achieve a unified approach to security, efficiency, and universality in the offline bill generation and management process. This results in better storage, management, and synchronization of offline bills. Attached Figure Description

[0071] To more clearly illustrate the technical solutions of the embodiments in this specification, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0072] Figure 1A This is a schematic diagram of the frame of the terminal device disclosed in this specification.

[0073] Figure 1B This is an example diagram illustrating the data flow during the offline bill generation process provided in this manual.

[0074] Figure 2 This is a schematic flowchart of an offline bill generation method provided in the embodiments of this specification;

[0075] Figure 3 This is another flowchart illustrating the offline bill generation method provided in the embodiments of this specification;

[0076] Figure 4 This is another flowchart illustrating the offline bill generation method provided in the embodiments of this specification;

[0077] Figure 5 This is a schematic block diagram of an offline bill generation device provided in an embodiment of this specification. Detailed Implementation

[0078] The technical solutions of the embodiments of this specification will now be described in detail with reference to the accompanying drawings.

[0079] This specification discloses an offline bill generation method and apparatus. The application scenarios and inventive concept of offline bill generation are described below:

[0080] When a transaction occurs while the account is offline, an offline statement must first be generated and stored locally on the device. Subsequently, when the device is connected to the internet, the offline statement generated during the offline period is synchronized to the corresponding server. This allows the server to transfer assets to the target account and update the balance based on the offline statement. The account can be either the payee's account or the payer's account.

[0081] Since offline billing is stored locally on the device while the account is offline, sufficient local storage space is required. Furthermore, secure local storage of offline billing is crucial to prevent double-spending.

[0082] Therefore, this specification provides an offline bill generation method applied to a terminal device. Given the different security levels of the information used in offline bill generation, such as... Figure 1A As shown, the terminal device may include a Trusted Execution Environment (TEE), a secure element based on cryptographic hardware, and a Rich Execution Environment (REE) to support the storage of data at different security levels and the execution of offline billing process steps at different security levels.

[0083] The Trusted Execution Environment (TEE) is a region on the digital processor of a terminal device, such as the CPU. This region provides a more secure space for the execution of data and code, ensuring their confidentiality and integrity. It achieves secure storage, secure computing, and other data processing involving security and privacy by creating a small, independently running operating system.

[0084] Secure elements based on cryptographic hardware can include, but are not limited to, Secure Element (SE) components. These are typically provided as chips and contain encryption / decryption logic circuitry to prevent external malicious parsing attacks and protect data security. It should be noted that a secure element is a hardware-based environment for encrypting and protecting data, thus offering a higher level of security than a TEE (Trusted Element Equipment).

[0085] The security level of a standard execution environment (REE) is relatively low, and payment-related applications run on the REE. These payment-related applications are the ones that generate transactions for the target account.

[0086] When a terminal device, while offline, detects a transaction from a target account, it obtains the basic transaction information and the target account's identity information within the TEE (Transaction Execution Environment). This information is then internally sent to the highest-level secure element. Within the secure element, the stored first private key is used to sign the basic transaction information and identity information, generating a first signature, which is then sent back to the TEE. In the TEE, with its superior computing power and ample storage space, the basic transaction information, identity information, and first signature are combined to generate and store an offline statement corresponding to the transaction. Figure 1B The diagram shown is an example of the data flow during the offline bill generation process.

[0087] In one implementation, the basic transaction information includes fundamental transaction information, such as at least one of the following: transaction amount, transaction ID, transaction type, transaction currency, transaction time, and information of both parties, such as the target account nickname and the nickname of the other account transacting with the target account. The transaction amount is the change in the transaction amount. The transaction ID is the identifier of the transaction and is unique. The transaction type includes, but is not limited to, payment, receipt, and refund. The transaction currency may include, but is not limited to, RMB, USD, and EUR. The target account nickname is unique and can uniquely identify the target account; the identities of both parties can be clearly identified through the target account nickname and the nickname of the other account transacting with the target account.

[0088] In one implementation, the identity information may include at least one of the following: the target account's ID, the ID of the operating institution to which the target account belongs, and the ID of the primary account to which the target account belongs. In one scenario, the target account may be referred to as an offline account, used for transactions when the terminal device is offline. The target account may be an offline account opened under a primary account. A primary account may include multiple offline accounts, and different offline accounts may belong to different operating institutions. The operating institution is the institution that opened the offline accounts.

[0089] In one embodiment, considering the different security levels of various information, such as basic transaction information, which is fundamental transaction information with a general security level, it can be stored in the storage area corresponding to the payment-related application running in the REE. As for identity information, which represents the identity information of the target account and involves the target account's privacy information, and is relatively more important than account assets, correspondingly, the security level of identity information is higher. To ensure that identity information is not easily tampered with, it can be stored in a TEE with a higher security level. Information involving account assets and encryption, such as the target account's balance and the key used for signing, is information with an even higher security level. Accordingly, this type of information can be stored in a secure element with a higher security level to prevent tampering and theft.

[0090] Correspondingly, such as Figure 1B As shown, the terminal device obtains basic transaction information from the payment-related applications running in the REE within the TEE, and obtains identity information in the secure storage area of ​​the TEE.

[0091] In this embodiment, the first private key, which requires a higher level of security, is stored in the secure element, and the signing steps for basic transaction information and identity information with a higher level of security are completed there. Furthermore, the assembly and generation of offline bills are implemented in the TEE, which has a higher level of security, faster data processing speed, and relatively larger storage space (compared to the secure element). This allows for the assembly, signing, generation, and storage of offline bills using data environments with different security levels. By fully utilizing the capabilities and characteristics of data environments with different security levels, the security, efficiency, and universality of the offline bill generation and management process are unified, thereby achieving better storage, management, and synchronization of offline bills.

[0092] Understandably, TEE offers high security and relatively large storage space, allowing for the secure storage of numerous offline statements. This ensures that offline statements are not easily tampered with and prevents storage shortages when the target account has many offline transactions and generates a large number of offline statements. Furthermore, TEE has a large data transmission capacity and strong computing power, resulting in high synchronization efficiency when synchronizing offline statements with connected terminal devices.

[0093] The offline bill generation method provided in this specification will be described in detail below with reference to specific embodiments.

[0094] Figure 2This document illustrates a flowchart of an offline bill generation method provided in this specification. The method is applied to a terminal device, which can be any device capable of data computation, processing, and storage, such as a mobile phone, tablet, smartwatch, or payment card. In one embodiment of this specification, the terminal device includes a Trusted Execution Environment (TEE) and a security element based on cryptographic hardware. The method includes:

[0095] S210: When a transaction is detected in an offline scenario, the basic transaction information and the identity information of the target account are obtained in the TEE.

[0096] When a terminal device is offline (i.e., not connected to the internet), and detects a transaction from a target account, it obtains the basic transaction information and the target account's identification information from the TEE. The target account can be either the payer's account or the payee's account.

[0097] Basic transaction information includes fundamental transaction details, such as at least one of the following: transaction amount, transaction ID, transaction type, transaction currency, transaction time, and information of both parties involved in the transaction, such as the target account's nickname and the nickname of the other account transacting with the target account. The transaction amount is the change in transaction value. The transaction ID is a unique identifier for this transaction. Transaction types include, but are not limited to, payments, receipts, deposits, and refunds. The transaction currency can include, but is not limited to, RMB, USD, and EUR. The target account's nickname is unique and can uniquely identify the target account.

[0098] The identity information is information that characterizes the identity of the target account and may include at least one of the following: the target account ID, the ID of the operating institution to which the target account belongs, and the ID of the main account to which the target account belongs. In one case, the target account may be an account of any offline wallet opened under the main account, and the target account may be referred to as an offline account, which can be used to conduct transactions when the terminal device is offline. A main account may include multiple offline accounts, and different offline accounts may belong to different operating institutions. The operating institution is the institution that opened the offline account. In one embodiment, the main account may refer to an Alipay Wallet account, and the target account may refer to an account of any hardware wallet opened under the Alipay Wallet.

[0099] In one implementation, considering the different security levels of different information, the corresponding information can be stored in environments with different security levels based on the security level of the information. Accordingly, the terminal device also includes a Free Execution Environment (REE). Basic transaction information, which is the basic information of the transaction, has a general security level and can be stored in the storage area corresponding to the payment-related application running in the REE. Identity identification information, which represents the identity information of the target account, involves the target account's privacy information and is relatively more important than account assets. Therefore, the security level of identity identification information is higher. To ensure that the identity identification information is not easily tampered with, it can be stored in a TEE with a higher security level. Accordingly, in step S210, when a transaction is detected in the target account in an offline scenario, the basic transaction information is obtained from the payment-related application running in the REE in the TEE, and the identity identification information is obtained in the secure storage area of ​​the TEE.

[0100] In this context, "payment-related application" can refer to the application on which the transaction was generated. If the main account refers to the Alipay Wallet account, then the corresponding payment-related application can be the Alipay Wallet application.

[0101] S220: Send basic transaction information and identity information to the secure element.

[0102] After obtaining the basic transaction information and identity information corresponding to the transaction, the terminal device sends the basic transaction information and identity information from the TEE to the secure element, wherein this transmission is an internal transmission of the terminal device. In one implementation, the secure element can be an SE. In another case, the secure element can be a built-in secure element of the terminal device or an external secure element of the terminal device. For example, if the terminal device is a mobile phone, the external secure element can be a SIM card-supported secure element.

[0103] S230: In the secure element, the basic transaction information and identity information are signed using the stored first private key to obtain the first signature.

[0104] The secure element can store higher-level security information related to account assets and encryption, such as the target account's balance and the key used for signing. Storing this type of information within the higher-security element prevents it from being tampered with or stolen. In this step, within the secure element, a preset hash algorithm is used to calculate the hash value of the basic transaction information and identity information, obtaining the corresponding hash value. Then, using the first private key stored in the secure element, this hash value is encrypted to obtain the first signature.

[0105] In one embodiment, the first private key and its corresponding first public key can be generated when the target account is opened. The generation process can be as follows: when the target account is opened, a first public-private key pair is generated based on a preset device public-private key pair and the ID of the main account to which the target account belongs, according to a preset public-private key pair generation algorithm. This first public-private key pair includes the first private key and its corresponding first public key. The preset public-private key pair generation algorithm can be a national cryptographic algorithm. The preset device public-private key pair can be generated when the payment-related application is first launched and stored in a TEE or secure element.

[0106] Subsequently, after generating the first public-private key pair, the first private key can be stored in the secure element of the terminal device, and the first public key can be stored in the secure element or TEE of the terminal device. In one embodiment, the first public key can also be published on the network.

[0107] S240: In the TEE, the basic transaction information, identity information and first signature are combined to generate the offline bill corresponding to the transaction and the offline bill is stored.

[0108] After obtaining the first signature in the secure element, the first signature is sent from the secure element to the TEE. In the TEE, the basic transaction information, identity information, and the first signature are combined to generate the offline invoice corresponding to the transaction. In one embodiment, the basic transaction information, identity information, and the first signature are combined according to a preset combination format, which includes the order in which the various types of information are combined. Based on the order in which the various types of information are combined, the basic transaction information, identity information, and the first signature are combined sequentially to obtain the offline invoice corresponding to the transaction.

[0109] For example, the order in which the various types of information included in the preset combination format are combined could be: transaction amount, transaction ID, transaction type, transaction currency, transaction time, target account nickname, nickname of the other account that transacted with the target account, target account ID, ID of the operating institution to which the target account belongs, ID of the main account to which the target account belongs, and the first signature. In the TEE, the basic transaction information, identity information, and first signature are sorted and combined in the above order. The above process is an example of combining basic transaction information, identity information, and the first signature and is not intended to be limiting.

[0110] After obtaining the offline invoice, store it in the TEE. Specifically, the offline invoice can be stored in the secure storage area of ​​the TEE.

[0111] In this embodiment, the first private key, requiring a higher security level, is stored in the secure element, where a higher-security signature step is performed on the basic transaction information and identity information. In the TEE, which has a slightly higher security level, faster data processing speed, and relatively larger storage space (compared to the secure element), offline bills are assembled, generated, and stored. This leverages data environments with different security levels to assemble, sign, and generate offline bills, fully utilizing the capabilities and characteristics of each security level's data environment. This achieves a unified approach to the security, efficiency, and universality of the offline bill generation and management process, resulting in better storage, management, and synchronization of offline bills. Understandably, the TEE offers high security and significantly more storage space than the secure element, allowing for the secure storage of a large number of offline bills. This ensures the offline bills are secure, trustworthy, and tamper-proof while preventing insufficient storage space when the target account has many offline transactions and generates a large number of offline bills.

[0112] In another embodiment of this specification, such as Figure 3 As shown, the method may include the following steps:

[0113] S310: When a transaction is detected in an offline scenario, the basic transaction information and the identity information of the target account are obtained in the TEE.

[0114] S320: Sends basic transaction information and identity information to the secure element.

[0115] S330: In the secure element, the basic transaction information and identity information are signed using the stored first private key to obtain the first signature.

[0116] S340: In the secure element, based on the underlying transaction information, update the target account's account balance after the transaction occurs.

[0117] S350: In the TEE, basic transaction information, identity information, and first signature are combined to generate an offline statement corresponding to the transaction and store the offline statement.

[0118] Among them, S310 and Figure 2 S210 shown is the same, S320 is the same. Figure 2 S220 shown is the same, S330 is the same. Figure 2 S230 shown is the same, S350 is the same. Figure 2 The S240 shown is the same, and will not be described again here.

[0119] In this embodiment, to prevent the target account balance from being tampered with, the target account balance is stored in a secure element. After obtaining the first signature, the transaction can be considered valid. Accordingly, in the secure element, based on the transaction amount and transaction type in the basic transaction information, the target account balance after the transaction occurs is updated. Specifically, if the transaction type is a payment type, the amount difference can be obtained by subtracting the transaction amount from the balance currently stored in the secure element; this amount difference is then used as the target account balance after the transaction occurs, updating the balance stored in the secure element to this amount difference. If the transaction type is a receipt type, the transaction amount can be added to the balance currently stored in the secure element; this sum is then used as the target account balance after the transaction occurs, updating the balance stored in the secure element to this sum.

[0120] Storing the target account's balance in a secure element can effectively prevent it from being tampered with, and to some extent, can prevent double-spending on the target account. In one scenario, where the transaction type is payment, the transaction amount may exceed the target account's current balance. In such cases, to avoid the target account owing funds, in another embodiment of this specification, the basic transaction information includes the transaction amount and transaction type; in S230, the following steps 11-12 may be included:

[0121] 11: When the transaction type is payment, in the secure element, determine whether the stored account balance is not less than the transaction amount.

[0122] 12: If the judgment result is yes, then use the stored first private key to sign the basic transaction information and identity information to obtain the first signature.

[0123] In this embodiment, it can be first determined whether the transaction type is a payment type. If the transaction type is determined to be a payment type, before signing in the secure element, it can be first determined whether the account balance currently stored in the secure element is not less than the transaction amount. If it is determined that the account balance currently stored in the secure element is not less than the transaction amount, then the basic transaction information and identity information are signed using the stored first private key to obtain the first signature.

[0124] The steps described above for determining whether a transaction is a payment type can be performed in the TEE or in the secure element; either is acceptable.

[0125] In another embodiment of this specification, S230 may further include the following step 13:

[0126] 13: If the account balance is determined to be less than the transaction amount, output a message indicating insufficient balance. In this embodiment, if the account balance is determined to be less than the transaction amount, the security element may not continue to execute the steps of signing the basic transaction information and identity information, and directly output a message indicating insufficient balance to remind the user that the balance of their target account is insufficient, and to change to another payment method or another account for offline payment.

[0127] In one implementation, based on storing offline bills in the TEE (Trusted Execution Environment), the terminal device can provide an offline bill query function. Specifically, in one embodiment, the terminal device can display the offline bill query information on the management interface of the payment-related application. When the terminal device detects a selection operation for querying offline bill information, it queries the offline bill from the TEE through the payment-related application via the TEE interface and displays the queried offline bill on the relevant interface of the payment-related application.

[0128] When the terminal device is offline, the offline transaction statements generated by the target account for each offline transaction are stored in the TEE of the terminal device to prevent tampering. When the target account conducts a transaction, its corresponding account balance will change accordingly. For asset security, it is necessary to verify and confirm the account balance after the transaction, and this verification and confirmation must be performed on the server used to manage account-related information. In another embodiment of this specification, in Figure 2 Based on the process shown, such as Figure 4 As shown, it may also include the following step S250: when the terminal device is detected to be connected to the network, synchronize the offline bill to the server via TEE.

[0129] When the terminal device is connected to the network, the network type can be either a wireless local area network or a cellular mobile network; either is acceptable. This specification does not limit the type of network connected to when the terminal device is connected to the network.

[0130] In one implementation, when the terminal device is detected to be connected to the network, the terminal device can directly send all offline bills generated during the most recent offline period to the server via TEE, thereby synchronizing the offline bills.

[0131] In another implementation, the target account owner can manually synchronize offline bills when the terminal device is connected to the internet. Accordingly, when the terminal device is detected to be connected to the internet, it displays a bill synchronization prompt; upon detecting a selection of the bill synchronization prompt, the offline bills are synchronized to the server via the TEE. In this embodiment, upon detecting a selection of the bill synchronization prompt, the terminal device can retrieve all unsynchronized offline bills from the TEE and then send all unsynchronized offline bills to the server via the TEE.

[0132] In one implementation, when the terminal device is detected to be connected to the internet, it displays a bill synchronization prompt on the management interface of the payment-related application. In one scenario, this prompt may be in text format, along with a selection button for the target account holder to choose whether to synchronize. When the target account holder's selection of the synchronization button is detected, it is considered that a selection of the bill synchronization prompt has been detected. The terminal device then identifies all unsynchronized offline bills in the TEE (Transaction Execution Environment) and sends all unsynchronized offline bills to the server via the TEE. In another scenario, the selection button may be highlighted when the terminal device is connected to the internet, and grayed out when the terminal device is offline.

[0133] After the TEE synchronizes the offline bills to the server, the server can determine the latest balance of the target account after each transaction in the offline bills based on the transaction type and amount in each received offline bill, as well as the current account balance of the target account stored locally on the server.

[0134] The server in this context refers to a server that manages information related to the target account, such as the account balance. In one implementation, the server can be the server of the operating organization that opened the target account.

[0135] To prevent offline bills from being intercepted and tampered with, potentially leading to asset loss in the target account, during offline bill synchronization, the offline bills to be synchronized can be encrypted and sent to the server. The server can decrypt the encrypted offline bills to obtain the offline bills and then update the account balance of the target account based on the offline bills, thereby ensuring asset security. Accordingly, in another embodiment of this specification, before synchronizing offline bills via TEE, the method may further include the following steps 21-23:

[0136] 21: In the TEE, the offline bill m is encrypted using a randomly generated symmetric key key to obtain the encrypted offline bill E1. key(m). In one implementation, a symmetric key key can be randomly generated in the TEE using a key randomization algorithm. Then, the offline bill m can be encrypted using the encryption algorithm E1 with this symmetric key key to obtain the encrypted offline bill E1. key (m). The key random generation algorithm can be any algorithm currently capable of randomly generating symmetric keys. The offline billing includes one or more offline bills currently pending synchronization in the TEE. The encryption algorithm E1 is a symmetric encryption algorithm.

[0137] 22: In the TEE, the symmetric key key is encrypted using the pre-set server public key S-Pk to obtain the encrypted symmetric key E2. S-pk (key). The pre-configured server public key S-Pk can be agreed upon in advance by the terminal device and the server and stored in the TEE. It can be understood that the encryption algorithm E2 here is an asymmetric encryption algorithm.

[0138] 23: Based on the encrypted symmetric key E2 S-pk (key) and the encrypted offline bill E1 key (m) Generates an offline billing synchronization message. In this step, the encrypted symmetric key E2 is obtained. S-pk (key) and the encrypted offline bill E1 key (m) After that, based on the preset message format, the encrypted symmetric key E2 can be used S-pk (key) and the encrypted offline bill E1 key (m) Assemble the offline billing synchronization message. The preset message format can be a message format related to the communication protocol between the terminal device and the server.

[0139] Accordingly, in step S250, an offline bill synchronization message is sent to the server via the TEE, so that the server can use the server private key, the first public key corresponding to the first private key, and the offline bill synchronization message to determine the latest balance of the target account.

[0140] The terminal device sends an offline bill synchronization message to the server via TEE. The server parses the offline bill synchronization message to obtain the encrypted symmetric key E2. S-pk (key) and the encrypted offline bill E1 key (m). Then, the server uses its locally securely stored private key S-Sk, which corresponds to the aforementioned publicly disclosed server public key S-Pk, to decrypt the encrypted symmetric key E2 using the decryption algorithm corresponding to E2. S-pk From (key), we can obtain the symmetric key; then, using the symmetric key, we can use the decryption algorithm corresponding to E1 to decrypt the encrypted offline bill E1. key(m), thus reconstructing the plaintext of the offline bill m. Then, using the transaction type and amount from the offline bill, the latest balance of the target account can be determined.

[0141] The foregoing description describes specific embodiments of this specification; other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than those shown in the embodiments, and the desired result may still be achieved. Furthermore, the processes depicted in the drawings do not necessarily need to follow the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0142] Corresponding to the above method embodiments, this specification provides an offline bill generation device 500, applied to a terminal device. The terminal device includes a Trusted Execution Environment (TEE) and a security element based on encrypted hardware, as shown in the schematic block diagram below. Figure 5 As shown, it includes:

[0143] The information acquisition module 510 is configured to obtain basic transaction information corresponding to the transaction and the identity information of the target account in the TEE when a transaction is detected to occur in an offline scenario.

[0144] The information sending module 520 is configured to send the basic transaction information and the identity information to the security element;

[0145] The signature module 530 is configured to sign the basic transaction information and the identity information using a stored first private key in the secure element to obtain a first signature;

[0146] The generation and storage module 540 is configured to combine the basic transaction information, the identity information, and the first signature in the TEE to generate an offline bill corresponding to the transaction and store the offline bill.

[0147] In one implementation, the terminal device further includes a general execution environment (REE).

[0148] The information acquisition module 510 is specifically configured to obtain the basic transaction information from the payment-related application running in the REE;

[0149] The identity information is obtained from the secure storage area of ​​the TEE.

[0150] In one implementation, the basic transaction information includes at least one of the following:

[0151] The transaction amount, transaction ID, transaction type, transaction currency, transaction time, target account nickname, and the nickname of another account that transacted with the target account.

[0152] In one implementation, the identity information includes at least one of the following:

[0153] The target account ID, the operating organization ID to which the target account belongs, and the main account ID to which the target account belongs.

[0154] In one implementation, the apparatus further includes:

[0155] An update module (not shown in the figure) is configured to, after obtaining the first signature, update the target account's account balance in the secure element based on the underlying transaction information after the transaction occurs.

[0156] In one implementation, the basic transaction information includes the transaction amount and transaction type;

[0157] The signature module 530 includes: a judgment unit (not shown in the figure), configured to, when the transaction type is a payment type, determine in the security element whether the stored account balance is not less than the transaction amount;

[0158] The signature unit (not shown in the figure) is configured to sign the basic transaction information and the identity information using the stored first private key if the judgment result is yes, thereby obtaining a first signature.

[0159] In one implementation, the signature module 430 further includes:

[0160] The prompt information output unit (not shown in the figure) is configured to output a prompt message indicating insufficient balance if it is determined that the account balance is less than the transaction amount.

[0161] In one implementation, the system further includes a synchronization module (not shown in the figure), configured to synchronize the offline bill to the server via the TEE when the terminal device is detected to be connected to the network.

[0162] In one implementation, the synchronization module is specifically configured to display a bill synchronization prompt when the terminal is detected to be connected to the network;

[0163] When a selection operation is detected for the bill synchronization prompt information, the offline bill is synchronized to the server via the TEE.

[0164] In one implementation, it further includes: a first encryption module (not shown in the figure), configured to encrypt the offline bill using a randomly generated symmetric key in the TEE to obtain an encrypted offline bill;

[0165] The second encryption module (not shown in the figure) is configured to encrypt the symmetric key using a preset server public key in the TEE;

[0166] The message generation module (not shown in the figure) is configured to generate an offline bill synchronization message based on the encrypted symmetric key and the encrypted offline bill.

[0167] The synchronization module is specifically configured to send the offline bill synchronization message to the server through the TEE, so that the server can use the server private key, the first public key corresponding to the first private key, and the offline bill synchronization message to determine the latest balance of the target account.

[0168] The above-described apparatus embodiments correspond to the method embodiments, and detailed descriptions can be found in the description of the method embodiments section, which will not be repeated here. The apparatus embodiments are derived based on the corresponding method embodiments and have the same technical effects as the corresponding method embodiments; detailed descriptions can be found in the corresponding method embodiments.

[0169] This specification also provides a computer-readable storage medium storing a computer program that, when executed in a computer, causes the computer to perform the offline bill generation method provided in this specification.

[0170] This specification also provides a computing device, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, it implements the offline bill generation method provided in this specification.

[0171] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on its differences from other embodiments. In particular, the embodiments for storage media and computing devices are basically similar to the method embodiments, and therefore are described more simply; relevant parts can be referred to the descriptions of the method embodiments.

[0172] Those skilled in the art will recognize that the functions described in the embodiments of this specification in one or more of the above examples can be implemented using hardware, software, firmware, or any combination thereof. When implemented in software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium.

[0173] The specific embodiments described above further illustrate the purpose, technical solutions, and beneficial effects of the embodiments in this specification. It should be understood that the above descriptions are merely specific implementations of the embodiments in this specification and are not intended to limit the scope of protection of this specification. Any modifications, equivalent substitutions, or improvements made based on the technical solutions of this specification should be included within the scope of protection of this specification.

Claims

1. A method for generating an offline bill, applied to a terminal device, the terminal device comprising a trusted execution environment (TEE), a secure element based on cryptographic hardware, and a regular execution environment (REE), the method comprising: in a case where a transaction of a target account in an offline scenario is detected, obtaining, in the TEE, basic transaction information from a payment-related application running in the REE; obtaining, in the TEE, identity information from a secure storage area of the TEE, the identity information being information representing an identity of the target account; sending the basic transaction information and the identity information to the secure element; signing, in the secure element, the basic transaction information and the identity information by using a stored first private key to obtain a first signature; and combining, in the TEE, the basic transaction information, the identity information, and the first signature to generate an offline bill corresponding to the transaction, and storing the offline bill. The basic transaction information comprises at least one of: a transaction amount, a transaction ID, a transaction type, a transaction currency, a transaction time, a nickname of the target account, and a nickname of another account that transacts with the target account. The identity information comprises at least one of: an ID of the target account, an ID of an operating organization to which the target account belongs, and an ID of a master account to which the target account belongs. After obtaining the first signature, the method further comprises: updating, in the secure element, an account balance of the target account after the transaction based on the basic transaction information. The basic transaction information comprises a transaction amount and a transaction type of the transaction. In the secure element, signing the basic transaction information and the identity information by using the stored first private key to obtain the first signature comprises: in a case where the transaction type is a payment type, determining whether the stored account balance is not less than the transaction amount; and if the determination result is yes, signing the basic transaction information and the identity information by using the stored first private key to obtain the first signature.

2. The method of claim 1, wherein, 6.The method of claim 5, further comprising: if it is determined that the account balance is less than the transaction amount, outputting prompt information of insufficient balance. 7.The method of any one of claims 1-4, further comprising: in a case where it is detected that the terminal device is in a network-connected state, synchronizing, by the TEE, the offline bill to a server.

3. The method of claim 1, wherein, The synchronizing, by the TEE, the offline bill to the server in the case where it is detected that the terminal device is in the network-connected state comprises: in a case where it is detected that the terminal device is in the network-connected state, displaying bill synchronization prompt information; and in a case where it is detected that a selection operation is performed on the bill synchronization prompt information, synchronizing, by the TEE, the offline bill to the server. 9.The method of claim 7, further comprising: encrypting, in the TEE, the offline bill by using a randomly generated symmetric key to obtain an encrypted offline bill.

4. The method of claim 1, wherein, ​ ​ 5. The method of claim 1 or 4, wherein, ​ ​ ​ ​ ​ ​ ​ ​ 8. The method of claim 7, wherein, ​ ​ ​ ​ ​ In the TEE, the symmetric key is encrypted by a preset server public key; Based on the encrypted symmetric key and the encrypted offline bill, an offline bill synchronization message is generated; The synchronization of the offline bill to the server by the TEE comprises: The offline bill synchronization message is sent to the server by the TEE, so that the server determines the latest balance corresponding to the target account by using a server private key, a first public key corresponding to the first private key, and the offline bill synchronization message. 10.An offline bill generation apparatus applied to a terminal device, the terminal device comprising a trusted execution environment (TEE), a secure element based on encryption hardware, and a regular execution environment (REE), the apparatus comprising: An information obtaining module configured to, in the case that a transaction of a target account in an offline scenario is detected, obtain, in the TEE, basic transaction information from a payment-related application running in the REE; In the TEE, identity information is obtained from a secure storage area of the TEE; the identity information is information representing the identity of the target account; An information sending module configured to send the basic transaction information and the identity information to the secure element; A signature module configured to, in the secure element, sign the basic transaction information and the identity information by using a stored first private key to obtain a first signature; A generation and storage module configured to, in the TEE, combine the basic transaction information, the identity information, and the first signature to generate an offline bill corresponding to the transaction, and store the offline bill. 11.A computing device comprising a memory and a processor, the memory storing executable code, and the processor implementing the method of any one of claims 1-9 when executing the executable code.

Images