Offline payment on-site proving method and system and storage medium

Abstract

The invention discloses an offline payment on-site proving method and system and a storage medium, relates to the technical field of block chain payment, and can solve the payment security problems of modern payment, money laundering, disputes and the like caused by the fact that a payment behavior cannot be strongly bound with physical on-site in an existing scanning payment process. According to the scheme, the method comprises the following steps: a terminal generates a two-dimensional code containing a session identifier and a Bluetooth connection parameter; the user side scans the two-dimensional code to obtain the session identifier and the Bluetooth connection parameter, and establishes a Bluetooth communication link with the terminal based on the Bluetooth connection parameter; the terminal and the user side carry out bidirectional challenge-response verification based on the Bluetooth communication link, and after the verification is passed, the user side generates a shared session key based on the session identifier, the exchanged challenge value and the feature information of the Bluetooth communication link; and after the user side uses the session key to carry out cryptographic calculation on the binding field of the session identifier, generating an on-site proof, and carrying out a transaction service after the on-site proof is verified to be valid.

Description

Technical Field

[0001] This application relates to the field of blockchain payment technology, and in particular to a method, system and storage medium for offline payment presence verification. Background Technology

[0002] With the popularization of digital currencies and mobile payments, offline QR code payments have become the mainstream method. In existing technologies, the payment process is usually as follows: the terminal (POS) displays a QR code containing the receiving address or order information, and the user scans the code using a mobile wallet application to independently complete operations such as signing and recording the transaction on the blockchain.

[0003] However, this payment model has a significant security and auditing flaw: the "payment behavior" cannot be strongly linked to "physical presence." Because QR codes can be screenshotted, photographed, and remotely transmitted, attackers or accomplices can complete scanning, signing, and payment from locations far from the merchant's site, easily leading to payment security issues such as proxy payments, money laundering, and disputes. Summary of the Invention

[0004] This application provides a method, system, and storage medium for offline payment presence verification, which can solve the payment security problems caused by the inability to strongly bind "payment behavior" to "physical presence" in the existing scanning payment process, leading to payment on behalf, money laundering, and disputes.

[0005] To address the above problems, this application provides the following technical solution: A first aspect of this application provides a method for proving presence in offline payments, the method comprising: The terminal generates a QR code containing a session identifier and Bluetooth connection parameters; The user terminal scans the QR code to obtain the session identifier and Bluetooth connection parameters, and establishes a Bluetooth communication link with the terminal based on the Bluetooth connection parameters; The terminal and the user terminal perform bidirectional challenge-response verification based on the Bluetooth communication link. After the verification is successful, the user terminal generates a shared session key based on the session identifier, the exchanged challenge value, and the characteristic information of the Bluetooth communication link. The user terminal uses the session key to perform cryptographic calculations on the binding field of the session identifier, generates a presence certificate, and performs transaction business after verifying the validity of the presence certificate.

[0006] As one possible implementation, the QR code serves as the sole entry point for the transaction interaction process, and the user initiates a transaction solely by scanning the QR code.

[0007] As one possible implementation, the terminal and the user terminal perform bidirectional challenge-response authentication based on a Bluetooth communication link, including: The terminal sends a first random challenge to the user terminal and verifies its response, while the user terminal sends a second random challenge to the terminal and verifies its response.

[0008] As one possible implementation, the terminal sends a first random challenge to the user terminal and verifies its response, including: The terminal generates a random number as the first random challenge and sends it to the user terminal. The user terminal uses a preset algorithm to calculate the first random challenge, obtains a first response, and returns the first response to the terminal, which then verifies the first response.

[0009] As one possible implementation, verifying the validity of the presence proof includes: The system accepts a verification data packet sent by the user terminal, the verification data packet containing the binding field of the session identifier and the proof of presence; Based on the session identifier, obtain the local record corresponding to the session, wherein the local record contains at least the exchanged challenge value and the characteristic information of the Bluetooth communication link; Based on the session identifier, the exchanged challenge value, and the feature information, the session key is reconstructed using a preset key derivation function; Using the reconstructed session key, a message authentication code is calculated on the bound field to obtain a calculation proof; The calculated proof is compared with the received proof of presence. If the comparison is consistent, the proof of presence is deemed valid.

[0010] As one possible implementation, the terminal and the user terminal perform bidirectional challenge-response verification based on a Bluetooth communication link, and after successful verification, the method further includes: The user terminal generates a check-in presence certificate based on the session identifier, terminal identifier, and timestamp, and sends the check-in presence certificate to the terminal. After verifying the validity of the check-in and presence certificate, the terminal determines that the user has physically arrived.

[0011] As one possible implementation, the characteristic information of the Bluetooth communication link includes: Bluetooth signal strength information and / or connection timestamp information.

[0012] As one possible implementation, the binding fields of the session identifier include: merchant identifier, timestamp, and summary value of transaction order information, wherein the transaction order information is encoded in the QR code or sent from the terminal to the user terminal via the Bluetooth communication link.

[0013] A second aspect of this application provides an offline payment presence verification system, the system comprising: a terminal and a user terminal; The terminal is used to generate a QR code containing a session identifier and Bluetooth connection parameters; The user terminal is used to scan the QR code to obtain the session identifier and Bluetooth connection parameters, and establish a Bluetooth communication link with the terminal based on the Bluetooth connection parameters; The terminal and the user terminal perform bidirectional challenge-response verification based on the Bluetooth communication link. After the verification is successful, the user terminal is also used to generate a shared session key based on the session identifier, the exchanged challenge value, and the feature information of the Bluetooth communication link. The user terminal is also used to generate an presence certificate by performing cryptographic calculations on the binding field of the session identifier using the session key, and to conduct transaction business after verifying the validity of the presence certificate.

[0014] In a third aspect of this application, a computer-readable storage medium is provided, on which a computer program is stored, and when executed by a processor, the computer program implements the offline payment presence verification method described in the first aspect of this application.

[0015] The beneficial effects of the technical solutions provided in this application include at least the following: This application provides an offline payment presence verification method. A terminal generates a QR code containing a session identifier and Bluetooth connection parameters. A user scans the QR code to obtain the session identifier and Bluetooth connection parameters, and establishes a Bluetooth communication link with the terminal based on the Bluetooth connection parameters. The terminal and the user perform bidirectional challenge-response verification based on the Bluetooth communication link. After successful verification, the user generates a shared session key based on the session identifier, the exchanged challenge value, and the characteristic information of the Bluetooth communication link. The user uses the session key to perform cryptographic calculations on the binding field of the session identifier to generate presence verification, and performs the transaction after verifying the validity of the presence verification.

[0016] The offline payment presence verification method provided in this application uses cryptographic methods to forcibly bind the "scan to start" action to the subsequently established Bluetooth communication session. This binding relationship is further comprehensively encrypted and signed with the specific merchant identity, precise timestamp, physical link fingerprint, and optional order information. This mechanism generates a digital presence credential that can be independently verified by a third party. It not only conclusively proves that the payment device is physically near the receiving device but also effectively resists remote attacks via signal relay, resolving the core security vulnerability of "remotely initiated transactions" in existing technologies.

[0017] Furthermore, this application generates and verifies "physical presence" without intervening in or constraining subsequent specific payment business logic (such as the type of blockchain used, the type of digital currency, the transaction signature method, or the source of the receiving address). This architectural design enables it to serve as a standardized secure middleware, seamlessly embedded in various existing or future wallet applications and payment clearing systems, greatly enhancing the versatility and applicability of the solution.

[0018] Furthermore, this application imposes extremely simplified requirements on merchant terminal hardware devices, requiring only a Bluetooth Low Energy communication module and a QR code display screen to support core functions, without the need to integrate additional dedicated security chips or undergo complex hardware upgrades. This significantly reduces deployment costs and technical transformation difficulties for merchants, facilitating the rapid promotion and widespread adoption of this security authentication solution in various offline commercial scenarios. Attached Figure Description

[0019] Figure 1 A flowchart illustrating an offline payment presence verification method provided in this application embodiment; Figure 2 This is a structural diagram of an offline payment presence verification system provided in an embodiment of this application. Detailed Implementation

[0020] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0021] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of embodiments of this disclosure, unless otherwise stated, "a plurality of" means two or more.

[0022] In addition, the use of “based on” or “according to” implies openness and inclusivity, because processes, steps, calculations or other actions “based on” or “according to” one or more conditions or values ​​can in practice be based on additional conditions or values ​​beyond those conditions.

[0023] With the popularization of digital currencies and mobile payments, offline QR code payments have become the mainstream method. In existing technologies, the payment process is usually as follows: the terminal (POS) displays a QR code containing the receiving address or order information, and the user scans the code using a mobile wallet application to independently complete operations such as signing and recording the transaction on the blockchain.

[0024] However, this payment model has a significant security and auditing flaw: the "payment behavior" cannot be strongly linked to "physical presence." Because QR codes can be screenshotted, photographed, and remotely transmitted, attackers or accomplices can complete scanning, signing, and payment from locations far from the merchant's location, easily leading to payment security issues such as proxy payments, money laundering, and disputes. Therefore, in offline digital currency payment scenarios, existing solutions lack an effective mechanism to rigorously prove that the payer's device and the payee's device are in the same physical space. Specifically, current technology has the following shortcomings: 1. Unable to defend against remote payment and money laundering risks: Traditional QR code payments can be screenshotted and transmitted remotely, allowing payment behavior to escape physical scene supervision, providing opportunities for illegal payment, money laundering and other activities.

[0025] 2. Lack of cryptographic presence binding: Relying solely on device connection status or QR code records, it is impossible to cryptographically bind the payment session to specific merchants, time, physical location, and other elements in an irrefutable manner.

[0026] 3. Existing anti-relay solutions have poor compatibility: Some solutions rely on specific hardware or are deeply coupled with blockchain protocols, making it difficult to adapt to diverse wallet ecosystems and payment systems.

[0027] 4. Conflict between security and user experience: Strong security solutions often require complex interactions or dedicated devices, while convenient solutions have security flaws.

[0028] Based on the aforementioned issues, the offline payment presence verification method provided in this application aims to design a generalized, lightweight, and highly secure solution capable of achieving reliable presence verification under the following stringent constraints: It does not limit the underlying blockchain, the type of digital currency, or the source of the receiving address; it does not require users to pre-disclose transaction details; it uses only the QR code displayed on the POS terminal as the sole point of interaction; it utilizes the general hardware capabilities of existing smart devices (camera, Bluetooth); and it generates digital credentials that can be independently audited and resist relay attacks. Ultimately, it ensures the physical authenticity of offline digital transactions from the source, filling the technological gap in the existing payment ecosystem regarding presence verification.

[0029] This application provides a method for proving presence in offline payments, such as... Figure 1 As shown, the method includes the following steps: Step 101: The terminal generates a QR code containing a session identifier and Bluetooth connection parameters.

[0030] The term "terminal" includes devices such as POS terminals, computer web interfaces, and cash registers; this application does not specifically limit the definition. The session identifier is a unique "session ID" for this transaction. The Bluetooth connection parameter is an "address" or "passport" used to instruct the user device how to find and connect to this specific terminal.

[0031] Furthermore, the QR code is the only legitimate entry point for the transaction interaction process. The user initiates a transaction only by scanning the QR code, thus ensuring that all subsequent operations begin with scanning this QR code.

[0032] Step 102: The user terminal scans the QR code to obtain the session identifier and Bluetooth connection parameters, and establishes a Bluetooth communication link with the terminal based on the Bluetooth connection parameters.

[0033] The user terminal can be a user's mobile phone, smartwatch, wallet app on the user's mobile phone, etc., and this application does not make specific limitations on it.

[0034] Specifically, users can use their wallet app to scan the QR code, parse it, and extract the session ID and Bluetooth parameters. Then, based on these specific Bluetooth parameters, the user can actively search for and connect to the terminal that generated the QR code.

[0035] Step 103: The terminal and the user terminal perform bidirectional challenge-response verification based on the Bluetooth communication link. After the verification is successful, the user terminal generates a shared session key based on the session identifier, the exchanged challenge value, and the feature information of the Bluetooth communication link.

[0036] The characteristic information of the Bluetooth communication link includes: Bluetooth signal strength information and / or connection timestamp information.

[0037] Optionally, in step 103 above, the terminal and the user terminal perform bidirectional challenge-response authentication based on a Bluetooth communication link, including: The terminal sends a first random challenge to the user terminal and verifies its response, while the user terminal sends a second random challenge to the terminal and verifies its response.

[0038] Specifically, the terminal generates a random number as a first random challenge and sends it to the user terminal; the user terminal uses a preset algorithm to calculate the first random challenge, obtains a first response, and returns the first response to the terminal, which then verifies the first response. Similarly, the user terminal generates a random number as a second random challenge and sends it to the terminal; the terminal uses a preset algorithm to calculate the second random challenge, obtains a second response, and returns the second response to the user terminal, which then verifies the second response.

[0039] The aforementioned two-way challenge-response authentication process between the terminal and the user terminal via Bluetooth communication confirms that the other end of the connection is a "real, real-time" device, not merely a recorder or repeater that relays signals. Even if an attacker could relay the signal, it would be extremely difficult to complete this round-trip verification process, which requires real-time computation, in a very short time.

[0040] After successful verification, both the user and the terminal generate a shared session key using the session identifier, the exchanged challenge value (i.e., two random numbers), and the characteristic information of the Bluetooth communication link. This session key is the foundation for all subsequent secure operations, and because it contains the characteristic information of the Bluetooth communication link, it is strongly correlated with "this connection that took place at this specific location".

[0041] Step 104: The user terminal uses the session key to perform cryptographic calculations on the binding field of the session identifier, generates a presence certificate, and performs the transaction after verifying the validity of the presence certificate.

[0042] The binding fields of the session identifier include: merchant identifier, timestamp, and summary value of transaction order information. The transaction order information is encoded in the QR code or sent from the terminal to the user terminal via the Bluetooth communication link.

[0043] Optionally, the above-described process for verifying the validity of the presence proof may include: receiving a verification data packet sent by the user terminal, the verification data packet containing the binding field of the session identifier and the presence proof; obtaining a local record corresponding to the session based on the session identifier, the local record containing at least the exchanged challenge value and the characteristic information of the Bluetooth communication link; reconstructing a session key based on the session identifier, the exchanged challenge value, and the characteristic information using a preset key derivation function; using the reconstructed session key to calculate the message authentication code on the binding field to obtain a calculated proof; comparing the calculated proof with the received presence proof, and if the comparison matches, determining that the presence proof is valid.

[0044] In actual execution, the user client uses the session key generated in the previous step to encrypt or sign the bound fields of the session identifier (including merchant identifier, timestamp, and digest value of transaction order information) to generate a digital credential named "Presence Certificate". The user client then sends this "Presence Certificate" to the terminal or backend system for validity verification.

[0045] During the verification process, the verifier receives a verification data packet from the user terminal. This packet contains two components: a presence certificate generated by the user terminal and a plaintext binding field corresponding to the certificate. The binding field includes at least a session identifier to uniquely identify this interaction, and typically also includes contextual information such as a timestamp and merchant identifier. Based on the received session identifier, the verifier retrieves the complete record corresponding to the session from local storage or a related database. This record must be pre-saved during the interaction and must include at least the random challenge values ​​exchanged by both parties during the challenge-response phase, and link fingerprint information characterizing the physical features of this Bluetooth communication. The verifier uses the same key derivation function as the user terminal, taking the session identifier, the challenge values ​​from both parties, and the link fingerprint as input, to recalculate and generate a session key. Since the input parameters are exactly the same as when the interaction occurred, the reconstructed session key is cryptographically identical to the original key generated by the user terminal and used for signature verification. The verifier uses the reconstructed session key to perform standard message authentication code calculations on the received plaintext binding field, generating a computational proof. Subsequently, this computational proof is compared bit-by-bit with the presence certificate submitted by the user terminal. If the two are completely consistent, it indicates that the proof submitted by the user is indeed generated by the correct session key and the binding fields have not been tampered with.

[0046] If the calculated proof matches the presence proof submitted by the user, it proves that the user did indeed participate in the complete near-field interaction, including a two-way challenge-response. Furthermore, it proves that the interaction occurred in a physical environment consistent with the recorded link fingerprint, possessing anti-relay properties; and the proof content is strongly bound to a specific session, time, and merchant identity, possessing non-repudiation. The core advantage of this verification mechanism lies in its objectivity and auditability: the verifier does not need to trust the user; it can independently complete the verification using only its own stored interaction records and publicly available cryptographic algorithms, providing a third-party auditable basis for presence evidence in offline digital transactions.

[0047] Optionally, the terminal and the user terminal perform bidirectional challenge-response verification based on a Bluetooth communication link, and after successful verification, the method further includes: The above process can be applied to offline payment scenarios. In addition, this application can also be used for check-in scenarios, as detailed below.

[0048] The user terminal generates a check-in presence certificate based on the session identifier, terminal identifier, and timestamp, and sends the check-in presence certificate to the terminal; after verifying the validity of the check-in presence certificate, the terminal determines that the user terminal has physically arrived.

[0049] In the above process, the terminal can be a check-in device in scenarios such as conferences, and the user terminal can be a participant's mobile phone. After establishing a Bluetooth communication link, the terminal and user terminal perform standard two-way challenge-response verification. This step ensures the authenticity of the device identity and the immediacy of communication, eliminates the possibility of relay attacks, and establishes a secure cryptographic session context for subsequent operations.

[0050] After successful verification, the user client does not need to obtain or process any order-related business information. Instead, it directly integrates the core metadata of this interaction, including: session identifier, terminal identifier, and timestamp. The session identifier, derived from the QR code, serves as a unique number for this check-in event. The terminal identifier identifies the check-in point (e.g., "Entrance 1 of Venue A"). The timestamp records the precise time the check-in occurred.

[0051] The client uses these fields to generate a sign-in presence certificate. The client sends this certificate to the terminal. Upon receiving it, the terminal verifies its integrity and authenticity by checking the digital signature (or message authentication code) of the certificate. The verification process confirms whether the certificate was generated from a legitimate session that has undergone the aforementioned two-way authentication, and whether the terminal identifier, timestamp, and other information in the certificate match local records. Once verification is successful, the terminal can technically determine that the client has physically arrived at its location at the corresponding time. This determination is based on the aforementioned unforgeable cryptographic evidence chain. At this point, the core "presence certificate" process is complete. After confirming the client's physical presence, the terminal can trigger subsequent business logic, such as marking the user as "present" in the sign-in system, controlling the gate or door lock to allow passage, and issuing a sign-in success notification. These subsequent business processes are completely decoupled from the security protocol for generating the certificate, demonstrating the flexibility of this scheme as a general identity verification foundation module.

[0052] In summary, the offline payment presence verification method provided in this application uses cryptographic methods to forcibly bind the "scan to initiate" action to the subsequently established Bluetooth communication session. This binding relationship is further comprehensively encrypted and signed with the specific merchant identity, precise timestamp, physical link fingerprint, and optional order information. This mechanism generates a digital presence credential that can be independently verified by a third party. It not only conclusively proves that the payment device is physically near the receiving device but also effectively resists remote attacks via signal relay, resolving the core security vulnerability of "remotely initiated transactions" in existing technologies.

[0053] Furthermore, this application generates and verifies "physical presence" without intervening in or constraining subsequent specific payment business logic (such as the type of blockchain used, the type of digital currency, the transaction signature method, or the source of the receiving address). This architectural design enables it to serve as a standardized secure middleware, seamlessly embedded in various existing or future wallet applications and payment clearing systems, greatly enhancing the versatility and applicability of the solution.

[0054] Furthermore, this application imposes extremely simplified requirements on merchant terminal hardware devices, requiring only a Bluetooth Low Energy communication module and a QR code display screen to support core functions, without the need to integrate additional dedicated security chips or undergo complex hardware upgrades. This significantly reduces deployment costs and technical transformation difficulties for merchants, facilitating the rapid promotion and widespread adoption of this security authentication solution in various offline commercial scenarios.

[0055] This application also provides an offline payment presence verification system, such as... Figure 2 As shown, the system includes: a terminal 10 and a user terminal 20; The terminal 10 is used to generate a QR code containing a session identifier and Bluetooth connection parameters; The user terminal 20 is used to scan the QR code to obtain the session identifier and Bluetooth connection parameters, and establish a Bluetooth communication link with the terminal 10 based on the Bluetooth connection parameters; The terminal 10 and the user terminal 20 perform bidirectional challenge-response verification based on the Bluetooth communication link. After the verification is successful, the user terminal 20 is also used to generate a shared session key based on the session identifier, the exchanged challenge value and the feature information of the Bluetooth communication link. The user terminal 20 is also used to generate an presence certificate by performing cryptographic calculations on the binding field of the session identifier using the session key, and to conduct transaction business after verifying the validity of the presence certificate.

[0056] Optionally, the QR code is the sole entry point for the transaction interaction process, and the user terminal 20 is also used to initiate a transaction solely by scanning the QR code.

[0057] Optionally, the terminal 10 is specifically used to send a first random challenge to the user terminal 20 and verify its response, while the user terminal 20 is specifically used to send a second random challenge to the terminal 10 and verify its response.

[0058] Optionally, the terminal 10 is specifically used to generate a random number as a first random challenge and send it to the user terminal 20; the user terminal 20 is specifically used to calculate the first random challenge using a preset algorithm, obtain a first response, and return the first response to the terminal 10; the terminal 10 is specifically used to verify the first response.

[0059] Optionally, terminal 10 is specifically configured to: receive a verification data packet sent by user terminal 20, the verification data packet containing a binding field of the session identifier and the presence proof; Based on the session identifier, obtain the local record corresponding to the session, wherein the local record contains at least the exchanged challenge value and the characteristic information of the Bluetooth communication link; Based on the session identifier, the exchanged challenge value, and the feature information, the session key is reconstructed using a preset key derivation function; Using the reconstructed session key, a message authentication code is calculated on the bound field to obtain a calculation proof; The calculated proof is compared with the received proof of presence. If the comparison is consistent, the proof of presence is deemed valid.

[0060] Optionally, the user terminal 20 is further configured to generate a check-in presence certificate based on the session identifier, the terminal 10 identifier, and the timestamp, and send the check-in presence certificate to the terminal 10; the terminal 10 is further configured to verify the validity of the check-in presence certificate and determine that the user terminal 20 has physically arrived.

[0061] Optionally, the characteristic information of the Bluetooth communication link includes: Bluetooth signal strength information and / or connection timestamp information.

[0062] Optionally, the binding fields of the session identifier include: merchant identifier, timestamp, and summary value of transaction order information, wherein the transaction order information is encoded in the QR code or sent from the terminal 10 to the user terminal 20 via the Bluetooth communication link.

[0063] The offline payment presence verification system provided in this application can execute the aforementioned offline payment presence verification method embodiments, and its implementation principle and technical effects are similar, so they will not be repeated here. Specific limitations of the offline payment presence verification system can be found in the limitations of the offline payment presence verification method above, and will not be repeated here.

[0064] In another embodiment of this application, a computer-readable storage medium is also provided, on which a computer program is stored, which, when executed by a processor, implements the steps of the offline payment presence verification method as described in the embodiments of this application.

[0065] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented using software programs, implementation can be, in whole or in part, in the form of a computer program product. This computer program product includes one or more computer instructions. When these computer instructions are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device containing one or more servers, data centers, etc., that can be integrated with the medium. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state disks, SSDs).

[0066] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0067] The above embodiments merely illustrate several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A method for proving presence in offline payments, characterized in that, The method includes: The terminal generates a QR code containing a session identifier and Bluetooth connection parameters; The user terminal scans the QR code to obtain the session identifier and Bluetooth connection parameters, and establishes a Bluetooth communication link with the terminal based on the Bluetooth connection parameters; The terminal and the user terminal perform bidirectional challenge-response verification based on the Bluetooth communication link. After the verification is successful, the user terminal generates a shared session key based on the session identifier, the exchanged challenge value, and the characteristic information of the Bluetooth communication link. The user terminal uses the session key to perform cryptographic calculations on the binding field of the session identifier, generates a presence certificate, and performs transaction business after verifying the validity of the presence certificate.

2. The method according to claim 1, characterized in that, The QR code is the sole entry point for the transaction interaction process, and the user initiates a transaction only by scanning the QR code.

3. The method according to claim 1, characterized in that, The terminal and the user terminal perform bidirectional challenge-response authentication based on a Bluetooth communication link, including: The terminal sends a first random challenge to the user terminal and verifies its response, while the user terminal sends a second random challenge to the terminal and verifies its response.

4. The method according to claim 3, characterized in that, The terminal sends a first random challenge to the user terminal and verifies its response, including: The terminal generates a random number as the first random challenge and sends it to the user terminal. The user terminal uses a preset algorithm to calculate the first random challenge, obtains a first response, and returns the first response to the terminal, which then verifies the first response.

5. The method according to claim 1, characterized in that, The verification of the validity of the presence testimonies includes: The system accepts a verification data packet sent by the user terminal, the verification data packet containing the binding field of the session identifier and the proof of presence; Based on the session identifier, obtain the local record corresponding to the session, wherein the local record contains at least the exchanged challenge value and the characteristic information of the Bluetooth communication link; Based on the session identifier, the exchanged challenge value, and the feature information, the session key is reconstructed using a preset key derivation function; Using the reconstructed session key, a message authentication code is calculated on the bound field to obtain a calculation proof; The calculated proof is compared with the received proof of presence. If the comparison is consistent, the proof of presence is deemed valid.

6. The method according to claim 1, characterized in that, The terminal and the user terminal perform bidirectional challenge-response verification based on a Bluetooth communication link, and after successful verification, the method further includes: The user terminal generates a check-in presence certificate based on the session identifier, terminal identifier, and timestamp, and sends the check-in presence certificate to the terminal. After verifying the validity of the check-in and presence certificate, the terminal determines that the user has physically arrived.

7. The method according to claim 1, characterized in that, The characteristic information of the Bluetooth communication link includes: Bluetooth signal strength information and / or connection timestamp information.

8. The method according to claim 1, characterized in that, The binding fields of the session identifier include: merchant identifier, timestamp, and summary value of transaction order information, wherein the transaction order information is encoded in the QR code or sent from the terminal to the user terminal via the Bluetooth communication link.

9. An offline payment presence verification system, characterized in that, The system includes: a terminal and a user terminal; The terminal is used to generate a QR code containing a session identifier and Bluetooth connection parameters; The user terminal is used to scan the QR code to obtain the session identifier and Bluetooth connection parameters, and to establish a Bluetooth communication link with the terminal based on the Bluetooth connection parameters. The terminal and the user terminal perform bidirectional challenge-response verification based on the Bluetooth communication link. After the verification is successful, the user terminal is also used to generate a shared session key based on the session identifier, the exchanged challenge value, and the feature information of the Bluetooth communication link. The user terminal is also used to generate an presence certificate by performing cryptographic calculations on the binding field of the session identifier using the session key, and to conduct transaction business after verifying the validity of the presence certificate.

10. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, implements the offline payment presence verification method according to any one of claims 1 to 8.

Images