Method for quick cancellation of benefits based on near field communication

Abstract

The present application relates to a benefit quick cancellation method based on near field communication, which is applied to a user mobile terminal, a cancellation terminal and a server. After the cancellation terminal detects that the mobile terminal enters the near field communication range, a one-time challenge is generated and sent to the mobile terminal through the near field. When the mobile terminal is validly logged in and is a bound device, the challenge, session identifier, device binding identifier and benefit identifier are uploaded to the server through the network to initiate a cancellation confirmation request. After the server verifies that the above information is valid, an intent lock associated with the cancellation session is generated, and second confirmation data is formed and sent to the cancellation terminal. At the same time, the mobile terminal generates first confirmation data containing session association information, which is sent to the cancellation terminal through the near field. The cancellation terminal receives the first and second confirmation data within a limited window, and when the session association information is consistent, the cancellation is executed and the result is reported. The server immediately marks the challenge and the intent lock as used to prevent repeated cancellation.

Description

Technical Field

[0001] This invention relates to the field of information processing technology, specifically to a method for rapid rights verification based on near-field communication. Background Technology

[0002] Current technologies, such as CN117710053A (a public disclosure of a method and system for store order verification based on NFC technology), achieve order verification through simple interaction between the user's mobile device and the store's NFC device. The basic process involves the order management system generating a verification coupon and sending it to the user's mobile device after purchase. Upon arrival at the store, the user interacts with the merchant's device using an NFC-enabled mobile device. While this improves the convenience of offline verification and reduces manual operation to some extent, it still has several shortcomings in its overall technical structure. This method relies primarily on a single NFC interaction to trigger the verification process. After the mobile device and merchant device complete near-field communication, verification information can be directly sent to the store system. The overall verification chain is relatively simple and lacks a multi-dimensional data consistency verification mechanism. Furthermore, there is no challenge response mechanism for verification sessions between the mobile terminal and the store system, nor is a strict session identifier binding relationship established. Therefore, if data duplication, communication replay, or unauthorized terminal emulation occurs during communication, the system struggles to effectively identify abnormal verification behavior.

[0003] This scheme lacks trusted binding verification of mobile device identities. Mobile devices can participate in the redemption process simply by obtaining redemption voucher information. The system does not introduce device-level keys or secure environment authentication mechanisms. This means that after obtaining redemption voucher data, attackers could initiate illegal redemption requests by simulating devices or tampering with the client environment, leading to the risk of stolen benefits or premature order redemption. The document does not verify the source of challenges in the NFC interaction process. NFC tags or devices are merely simple triggering media, and the data they send lacks uniqueness and non-reusability control. Therefore, when NFC tag data is copied or read by malicious devices, attackers may reuse this information in other terminal environments, creating a replay attack risk. The scheme also lacks a locking mechanism for the redemption process on the server side. After the store system confirms redemption, it directly generates a redemption record without establishing a temporary occupancy control mechanism for the same order or the same redemption process. Therefore, in high-concurrency scenarios, duplicate redemption requests may occur, leading to duplicate order redemption or inconsistent data status.

[0004] The document also lacks a clear security confirmation process at the user interaction level. Users only need to bring their mobile devices close to the NFC tag to trigger the verification operation, without any secondary confirmation or information prompts from the system. Users cannot intuitively confirm the current verification terminal or specific verification rights information, which can easily lead to the risk of accidental verification or verification being induced by malicious tags in practical applications. The solution also lacks a control mechanism for the lifecycle of verification data, lacking one-time challenges, session serial numbers, or usage status markers. Therefore, when verification data is intercepted during network transmission, the system has difficulty preventing it from being submitted and used again. Summary of the Invention

[0005] The purpose of this invention is to provide a method for rapid rights cancellation based on near-field communication, thereby addressing some of the drawbacks and shortcomings pointed out in the background art.

[0006] The present invention addresses the aforementioned technical problems by employing the following technical solution: a fast rights verification method based on near-field communication, comprising: an application to a user's mobile terminal, a verification terminal, and a server; the verification terminal generates a one-time challenge and sends it via near-field communication after detecting that the mobile terminal has entered the near-field communication range; when the mobile terminal is validly logged into the account and bound to the device for the account, it sends the challenge, session identifier, device binding identifier, and rights identifier to the server via the network to form a verification confirmation request; After verifying the session identifier, device binding identifier, and the validity of the challenge, the server generates an intent lock associated with the verification session and forms second confirmation data for network transmission, which is then sent to the verification terminal. The mobile terminal generates first confirmation data associated with the verification session for near-field transmission and sends it to the verification terminal via near-field transmission. The first confirmation data includes at least session association information corresponding to the session identifier and the one-time challenge. When the verification terminal obtains the first confirmation data and the second confirmation data within the limited window and the session association information is consistent, it performs verification and reports the result. The server sets the challenge and intent lock to be used to prevent duplicate verification.

[0007] Furthermore, the device binding identifier is determined by the public key digest corresponding to the non-derivative key generated by the mobile terminal in the protected environment; when the mobile terminal sends a verification confirmation request to the server, it signs the data containing the one-time challenge, session identifier, and rights identifier and sends it with the request; the server verifies the signature before generating the intent lock to confirm that the login device that initiated the request is the binding device.

[0008] Furthermore, after generating a one-time challenge, the verification terminal sends a challenge issuance receipt to the server. The receipt includes at least the terminal identifier, challenge summary, and issuance time. The server determines the challenge is valid and generates an intent lock only if the challenge in the verification confirmation request matches the receipt and is within a limited window; otherwise, it refuses to generate the lock.

[0009] Furthermore, the first confirmation data includes an presence confirmation identifier generated by the mobile terminal after receiving the one-time challenge and completing a confirmation through secure interaction, and is bound to the session identifier and the one-time challenge; the mobile terminal sends the presence confirmation identifier or its summary to the server via the network along with the verification confirmation request; the server writes a verification field corresponding to the presence confirmation identifier into the second confirmation data; the verification terminal performs verification only when the first confirmation data, the second confirmation data, and the verification field correspond to each other and are within a limited window.

[0010] Furthermore, after the mobile terminal generates the non-exportable key, it sends a key generation certificate output by the protected environment to the server; the server verifies the key generation certificate before accepting the device binding identifier, and determines the device binding identifier with the corresponding public key digest after successful verification.

[0011] Furthermore, the one-time challenge includes a verification terminal identifier and a monotonically increasing session sequence number; when the mobile terminal signs, the terminal identifier and session sequence number are overwritten together; after the signature verification is successful, the server verifies that the session sequence number is increasing relative to the device binding identifier and that the one-time challenge has not been used; otherwise, it refuses to generate an intent lock.

[0012] Furthermore, before generating the intent lock, the server sends a signature field identifier corresponding to the current verification session to the mobile terminal. This sending is done via the network to the mobile terminal or forwarded by the verification terminal. When the mobile terminal sends a verification confirmation request, it adds the signature field identifier to the signature data. When the server verifies the signature, it checks whether the signature field identifier is consistent with the verification session, binds the signature field identifier to the intent lock, and sets it to "used" to restrict the reuse of signatures across sessions or across benefits.

[0013] Furthermore, the secure interaction includes explicitly displaying the verification terminal identifier or rights identifier on the mobile terminal; the mobile terminal generates the presence confirmation identifier only after user confirmation, and binds the presence confirmation identifier to the verification terminal identifier or rights identifier.

[0014] Furthermore, the presence confirmation identifier includes a single confirmation sequence number under the same session identifier and is written into the first confirmation data; the server records the availability status of the sequence number in the verification field of the second confirmation data, and sets the sequence number as used after the verification report is submitted, so as to prevent the presence confirmation identifier from being replayed or split and reused.

[0015] Furthermore, when the mobile terminal explicitly presents the verification terminal identifier or the rights identifier, it also presents a short summary prompt code derived from the one-time challenge; the user confirmation includes a confirmation of the consistency of the short summary prompt code, and the presence confirmation identifier is bound to the short summary prompt code.

[0016] The beneficial effects of this invention are as follows: A dual-channel verification mechanism combining near-field communication and network communication is established between the user's mobile terminal, the verification terminal, and the server. When the mobile terminal enters the near-field communication range, the verification terminal generates a one-time challenge and initiates a verification confirmation request to the server via the network, while simultaneously sending first confirmation data through the near-field link. After verifying the session identifier, device binding identifier, and challenge validity, the server generates an intent lock associated with the verification session and sends second confirmation data to the verification terminal. Within a limited time window, the verification terminal only performs verification if the session association information in the first confirmation data and the second confirmation data are consistent. This achieves a collaborative verification mechanism of near-field presence verification and server authorization confirmation, which not only improves the processing efficiency of rights verification but also effectively avoids abnormal verification problems caused by remote forged requests or single-channel data tampering.

[0017] The system employs a device-bound key signature mechanism, a challenge issuance receipt verification mechanism, and an on-site confirmation identification mechanism to perform multi-dimensional verification of device identity, challenge source, and user confirmation behavior during the reconciliation process. Simultaneously, it restricts signature reuse across sessions through signature field identification, prevents replay attacks through single-confirmation serial numbers and challenge usage status control, and provides user-perceptible confirmation by displaying terminal identification and challenge-derived prompt codes through the user interface. Attached Figure Description

[0018] Figure 1 This is a flowchart illustrating the fast rights cancellation logic of this invention based on near-field communication.

[0019] Figure 2 This is a schematic diagram illustrating the relationship between dual-channel confirmation delay and the effective challenge window in Embodiment 1 of the present invention.

[0020] Figure 3 This is a schematic diagram of the waterfall relationship from total amount to successful reimbursement requests in Embodiment 1 of the present invention.

[0021] Figure 4 This is a schematic diagram of the polar coordinate intensity formed by the abnormal interception in Embodiment 1 of the present invention.

[0022] Figure 5 This is a schematic diagram of the timing of manual confirmation and dual-channel confirmation within a limited window in Embodiment 2 of the present invention.

[0023] Figure 6 This is a schematic diagram illustrating how the short digest prompt code consistency verification suppresses the false cancellation rate in Embodiment 2 of the present invention.

[0024] Figure 7 This is a schematic diagram of the closed path from total quantity to success in the statistical period request in Embodiment 2 of the present invention. Detailed Implementation

[0025] The specific embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0026] Combined with appendix Figure 1 This invention relates to a rapid rights verification method based on near-field communication, applied to a system architecture involving collaboration between a user's mobile terminal, a verification terminal, and a server. The user's mobile terminal is a smart device with a rights service application installed, the verification terminal is a processing device deployed in an offline service scenario, and the server is a backend system providing account management, device binding management, and rights management functions.

[0027] When a user enters the near-field communication range of the verification terminal with a logged-in mobile device, the verification terminal polls and detects surrounding devices via its near-field communication module. Upon detecting a mobile device conforming to the communication protocol entering a preset sensing distance, the verification terminal immediately generates one-time challenge data. The one-time challenge is a random number or a random string containing time information, valid only in the current verification session, used to identify this verification interaction and prevent replay. The verification terminal sends the one-time challenge to the mobile device via the near-field communication link, simultaneously activating the corresponding local timing window.

[0028] If the account is within its login validity period and a device binding relationship exists, the mobile terminal generates a session identifier corresponding to this verification. The session identifier is used to distinguish different verification processes and establish an association with the one-time challenge. Subsequently, the mobile terminal reads the device binding identifier corresponding to the current device from the local secure storage area and obtains the rights identifier that the user intends to use.

[0029] The mobile terminal encapsulates the one-time challenge, session identifier, device binding identifier, and rights identifier into a verification confirmation request message. The verification confirmation request is sent to the server via a secure network channel. Upon receiving the request, the server initiates the verification process, providing the basis for subsequently generating a verification intent lock and confirmation data.

[0030] After receiving the verification confirmation request from the mobile terminal, the server parses the request data and sequentially verifies the validity of the session identifier, device binding identifier, and one-time challenge. The server retrieves the verification session record in the current system based on the session identifier to confirm that the session identifier has not been used and has not exceeded the preset validity period. Subsequently, the server queries the account device binding relationship based on the device binding identifier to confirm that the mobile terminal initiating the request is a legitimate bound device for the account.

[0031] Intent locks are used to mark the current reversal action on the server side to ensure that only one valid reversal process is allowed to continue at the same time for the same benefit.

[0032] After generating the intent lock, the server further constructs second confirmation data for network transmission. This second confirmation data includes confirmation information corresponding to the verification session and a session association field used to verify verification consistency. The server sends the second confirmation data to the corresponding verification terminal via the network communication link, enabling the verification terminal to obtain verification confirmation evidence from the server side and cache the data locally to await matching with data from the mobile terminal side.

[0033] The first confirmation data is transmitted to the verification terminal via the near-field communication link and serves as the presence confirmation information on the mobile terminal side. The first confirmation data includes at least session association information corresponding to the session identifier and the one-time challenge, enabling the verification terminal to confirm that the mobile terminal and the server confirmation process belong to the same verification session.

[0034] After generating the first confirmation data, the mobile terminal sends the data to the verification terminal via the near-field communication module.

[0035] After receiving the first confirmation data and the second confirmation data within the limited window, the verification terminal performs a consistency check on the session association information in the two types of data.

[0036] The verification terminal extracts session association information corresponding to the session identifier and one-time challenge from the first confirmation data, and simultaneously reads the corresponding verification information generated by the server from the second confirmation data. The verification terminal compares the above information, and when it confirms that the two types of data correspond to the same verification session and the one-time challenge is consistent, it determines that the current mobile terminal and server-side confirmation process belong to the same legitimate verification request. If any data is missing, exceeds the limit window, or the session association information is inconsistent, the verification terminal terminates the current verification process and discards the relevant data.

[0037] Once the reconciliation terminal completes the consistency verification and confirms data matching, it executes the rights reconciliation operation. The reconciliation operation includes recording the used status of rights locally on the reconciliation terminal and generating corresponding reconciliation result data. Subsequently, the reconciliation terminal reports the reconciliation result to the server via a network communication link, enabling the server to synchronously update the rights usage records.

[0038] After receiving the verification result reported by the verification terminal, the server updates the state associated with that session. The server marks the previously generated one-time challenge as used and simultaneously updates the intent lock state corresponding to that session to completed.

[0039] The device binding identifier is determined by the public key digest corresponding to a non-exportable key generated by the mobile terminal in a protected environment. When binding a device, the mobile terminal generates a key pair in its secure storage area. The private key is restricted to the protected environment and cannot be exported, while the public key is used to generate the device binding identifier. The mobile terminal performs a digest calculation on the public key to form the device binding identifier, then associates this identifier with the user account and uploads it to the server for registration and storage.

[0040] During subsequent rights verification, after the mobile terminal receives the one-time challenge from the verification terminal and generates a verification confirmation request, the mobile terminal combines the one-time challenge, session identifier, and rights identifier into data to be signed. The mobile terminal uses the private key in the protected environment to perform a digital signature operation on the data to be signed and sends the generated signature result to the server along with the verification confirmation request. Because the signing process is completed in a protected environment and the private key cannot be exported, external applications or malicious programs cannot forge a legitimate signature.

[0041] Upon receiving the verification confirmation request, the server verifies the signature before generating the intent lock. The server retrieves the corresponding public key digest based on the device binding identifier carried in the request and uses this public key to verify the signature submitted by the mobile terminal. If the signature verification is successful and the device binding identifier in the request matches the account binding record, the server confirms that the current request originates from a legitimate bound device.

[0042] After generating a one-time challenge, the verification terminal calculates a digest value for the challenge and combines the terminal identifier, challenge digest, and challenge issuance time to form challenge issuance receipt data. The terminal identifier uniquely identifies the current verification terminal device, the challenge digest identifies the generated one-time challenge without directly revealing the original challenge content, and the issuance time records the time the challenge was generated. The verification terminal sends the challenge issuance receipt to the server via a network communication link, where the server records and saves it, establishing a connection with the corresponding terminal.

[0043] When the server subsequently receives a verification confirmation request from the mobile terminal, it extracts the one-time challenge information from the request data and calculates the corresponding challenge summary. The server then matches this challenge summary with a previous challenge issuance receipt submitted by the verification terminal to confirm that the challenge indeed originated from a registered verification terminal. Simultaneously, the server uses the issuance time in the receipt to determine if the challenge is within a preset time window, ensuring that the challenge is used within its validity period.

[0044] When the server confirms that the challenge in the reconciliation confirmation request matches the challenge issuance receipt and that the time window has not expired, the server determines that the one-time challenge is valid and continues to execute the subsequent verification process, generating an intent lock associated with the reconciliation session in the system. If the server does not find a corresponding challenge issuance receipt, or finds that the challenge summary is inconsistent, or determines that the challenge has exceeded the time window, the server refuses to generate an intent lock and terminates the current reconciliation process.

[0045] The non-exportable key is generated and stored in the protected environment of the mobile terminal. This protected environment can be the terminal's secure execution area or secure storage area. Its characteristic is that the generated private key cannot be exported to the ordinary application environment, thus ensuring the security of the key.

[0046] During device binding, the mobile terminal calls the key generation interface in the protected environment to generate a key pair. The private key is stored within the protected environment, while the public key is used for subsequent authentication. After completing key generation, the protected environment generates a key generation certificate according to system preset rules. The key generation certificate proves that the key was indeed generated by the terminal's protected environment and that the corresponding private key is in a secure, non-exportable state. The mobile terminal then sends the public key information and the key generation certificate to the server via a secure network channel.

[0047] After receiving the aforementioned data, the server verifies the key generation certificate. The verification process includes checking the source of the key generation certificate and the completeness of its content to confirm that the key pair was indeed generated by the mobile terminal's protected environment, and not forged by a normal application environment. Once the server verifies the key generation certificate, it considers the device to have a trusted hardware security foundation.

[0048] After confirming the trustworthiness of the key generation source, the server performs a digest calculation on the public key submitted by the mobile terminal and uses the resulting public key digest as the device binding identifier. The server then establishes a binding relationship between the device binding identifier and the user account and saves it for device identity verification in subsequent revocation requests.

[0049] When generating a one-time challenge, the verification terminal combines its terminal identifier with the session number corresponding to the current verification session to form challenge data. The session number increments continuously according to the internal counting rules of the verification terminal, so that each verification interaction has a clear sequential identifier.

[0050] After the verification terminal sends the one-time challenge to the mobile terminal via near-field communication, the mobile terminal, when generating a verification confirmation request, includes the terminal identifier and session sequence number from the challenge data in the data to be signed. The mobile terminal uses a non-derivative private key in a protected environment to digitally sign the data containing the one-time challenge, terminal identifier, session sequence number, session identifier, and rights identifier, ensuring that the above information is not tampered with during transmission and can uniquely correspond to this verification session.

[0051] After receiving the verification confirmation request from the mobile terminal, the server verifies the signature using the public key corresponding to the device binding identifier. Once the signature verification is successful, the server further parses the data content covered by the signature and verifies the terminal identifier and session sequence number. The server retrieves the most recent session sequence number recorded when the device previously participated in the verification process based on the device binding identifier and determines whether the session sequence number in the current request is increasing relative to that record value.

[0052] If the server confirms that the session sequence number is incrementing and the one-time challenge has not been recorded as used by the system, the server determines that the challenge is a valid challenge and continues to execute the subsequent process to generate an intent lock associated with the current reimbursement session. If the server detects that the session sequence number is not incrementing, or finds that the one-time challenge has already been used, the server refuses to generate an intent lock and terminates the current reimbursement process.

[0053] After the server receives the initial verification request from the mobile terminal and completes the basic verification, it generates a unique signature field identifier based on the current verification session. This identifier is associated with the session identifier and the rights identifier to identify the signature scope of this verification process. The server then sends the signature field identifier to the mobile terminal via the network communication link. In some application scenarios, if communication between the mobile terminal and the server needs to be relayed through the verification terminal, the server can also first send the signature field identifier to the verification terminal, which then forwards it to the mobile terminal, completing the distribution of the signature field identifier.

[0054] Upon receiving the signature field identifier, the mobile terminal adds the signature field identifier to the data to be signed when constructing the verification confirmation request and generating the signature. The mobile terminal uses a non-exportable private key in the protected environment to sign the data containing the one-time challenge, session identifier, stake identifier, and signature field identifier, forming a signature result bound to the current verification session, and sends this signature to the server along with the verification confirmation request.

[0055] After receiving the signature data submitted by the mobile terminal, the server verifies the signature using the public key corresponding to the device binding identifier. Based on successful signature verification, the server further verifies whether the signature field identifier contained in the signature data matches the current verification session. When the server confirms that the signature field identifier matches the current session, the server establishes a binding relationship between the signature field identifier and the intent lock generated in this verification process, and records the signature field identifier as used on the server side.

[0056] After receiving a one-time challenge, the mobile terminal presents the current verification request information to the user through the application interface and guides the user to complete a confirmation operation. Upon completion of the confirmation operation, the mobile terminal generates an presence confirmation identifier and writes this identifier into the first confirmation data. This first confirmation data, which includes session association information and the presence confirmation identifier, is sent to the verification terminal via near-field communication, enabling the verification terminal to recognize that the mobile terminal has completed the user's confirmation process.

[0057] Upon receiving the request, the server records the presence confirmation identifier and writes the corresponding verification field when generating the second confirmation data. The verification field is used to verify the consistency of data between the mobile terminal and the server during the subsequent verification phase.

[0058] After receiving the first confirmation data sent by the mobile terminal via near-field communication and the second confirmation data sent by the server via the network within a limited time window, the verification terminal extracts the corresponding session association information from the two types of data and compares it with the verification fields. When the verification terminal confirms that the presence confirmation identifier in the first confirmation data matches the verification field in the second confirmation data, and all data is within the limited time window, the verification terminal determines that the verification request is legitimate and valid and executes the verification operation.

[0059] Secure interaction is used to explicitly present key information about the current revocation request to the user on the mobile terminal, thereby preventing the user from completing the revocation operation without their knowledge. The mobile terminal explicitly displays the revocation terminal identifier or the type of benefit on the interface, enabling the user to identify the service terminal or the type of benefit being revoked.

[0060] After receiving the one-time challenge from the verification terminal and completing the initial data preparation, the mobile terminal displays the verification terminal identifier or rights identifier information through the application interface and prompts the user to confirm. Confirmation can be completed by clicking the confirmation button or by following the system's predefined confirmation method. Only after the user completes the confirmation will the mobile terminal continue with the subsequent verification process.

[0061] After receiving a confirmation command from the user, the mobile terminal generates an presence confirmation identifier. The presence confirmation identifier is generated by the mobile terminal based on the current verification session information and is bound to the displayed verification terminal identifier or rights identifier.

[0062] When generating an presence confirmation identifier, the mobile terminal generates a unique confirmation sequence number based on the session identifier corresponding to the current verification session. This sequence number is used to identify a confirmation operation within the current session and is associated with the session identifier and the one-time challenge. The mobile terminal then writes the presence confirmation identifier containing the confirmation sequence number into the first confirmation data and sends it to the verification terminal via near-field communication.

[0063] When a mobile terminal sends a verification confirmation request to the server, it also sends a presence confirmation identifier or its summary, enabling the server to obtain the corresponding confirmation sequence number information. When the server processes the verification request and generates second confirmation data, it records the current availability status of the confirmation sequence number in the verification field of the second confirmation data. An availability status indicates that the sequence number has not yet participated in the actual verification operation and is in a pending state, allowing the verification terminal to continue performing consistency checks within a defined window.

[0064] After the verification terminal completes the matching of the first confirmation data and the second confirmation data and executes the verification, it will report the verification result to the server. After receiving the report information from the verification terminal, the server will update the status of the confirmation sequence number corresponding to the current verification session, changing it from an available state to a used state.

[0065] If the system subsequently detects that the same serial number has been submitted to participate in the verification process, the server will determine that the request has the risk of replay or splitting and reuse, and will refuse to continue generating intent locks or executing subsequent verification processing.

[0066] The short digest prompt code is calculated by the mobile terminal based on the received one-time challenge data and is a short identifier of fixed length generated by a preset digest algorithm.

[0067] After receiving a one-time challenge from the redemption terminal, the mobile terminal performs a digest calculation on the challenge data and generates a short digest prompt code. Subsequently, the mobile terminal simultaneously displays the redemption terminal identifier or rights identifier and the short digest prompt code in the application interface, allowing the user to see the corresponding prompt information when confirming the redemption operation.

[0068] When a user performs a confirmation operation, the mobile terminal not only records the user's confirmed verification request but also verifies the consistency of the presented short digest prompt code. After the confirmation process is complete, the mobile terminal generates an presence confirmation identifier and establishes a binding relationship between this identifier and the short digest prompt code during the generation process. Since the short digest prompt code originates from a one-time challenge, this binding relationship indirectly associates the user's confirmation action with the challenge data in the current verification session.

[0069] The generated presence confirmation identifier is then written into the first confirmation data and participates in subsequent verification processes. When performing data consistency verification, the server and verification terminal can indirectly verify whether the challenge information corresponding to the short digest prompt code is consistent through the presence confirmation identifier.

[0070] Example 1: In a promotional event organized at a commercial venue, a user entered a service point with their mobile device. The verification terminal continuously monitored the status of surrounding devices via a near-field communication (NFC) module. When the mobile device entered a preset NFC range, the verification terminal immediately generated a one-time challenge and sent it to the mobile device via the NFC link. This one-time challenge included a verification terminal identifier and a monotonically increasing session sequence number, used to identify the source of the current verification terminal and the order of the session. The challenge validity window was set to 20 seconds. Simultaneously with sending the one-time challenge, the verification terminal also sent a challenge issuance receipt to the server. The challenge issuance receipt included at least the terminal identifier, challenge summary, and issuance time. Upon receiving the receipt, the server created a pending verification record as a basis for subsequently judging the authenticity and timeliness of the challenge, thus preventing forged challenges from directly entering the verification process.

[0071] Prior to this account verification, a user's mobile device had successfully logged in and was identified by the server as a device bound to that account. This binding was established by the mobile device generating a non-exportable key within a protected environment. The protected environment then outputs a key generation certificate. The server verifies the key generation certificate; upon successful verification, it extracts the corresponding public key digest and identifies it as the device binding identifier. Because the non-exportable key cannot be exported from the protected environment, even if an attacker obtains application-layer session data, they cannot reproduce the same signature capability on other devices. Therefore, this effectively restricts unbound devices from impersonating accounts for account verification.

[0072] When a mobile terminal receives a one-time challenge, it verifies the local account login status and reads the bound device information corresponding to the current account. If the account is valid and the device is bound, the mobile terminal generates a verification confirmation request. This verification confirmation request includes the one-time challenge, session identifier, device binding identifier, and benefit identifier. Simultaneously, the server sends a signature field identifier, uniquely corresponding to this verification session, to the mobile terminal. The signature field identifier can be sent directly to the mobile terminal over the network or forwarded via the verification terminal. The mobile terminal then uses a non-exportable key in a protected environment to sign the challenge, session identifier, benefit identifier, terminal identifier, monotonically increasing session sequence number, and signature field identifier, and sends the signature result to the server along with the verification confirmation request. By including the signature field identifier in the signature coverage, the copying and use of the signature result between different sessions or different benefits can be restricted.

[0073] After receiving the verification confirmation request, the server verifies whether the session identifier is in a valid session state. Then, based on the device binding identifier, it searches for the registered public key digest and verifies the signature data submitted by the mobile terminal. Only when the verification passes does the server confirm that the request was initiated by the bound device, thus eliminating the possibility of a forged request from a regular copying terminal. Subsequently, the server performs a receipt matching verification on the one-time challenge, comparing the challenge information in the verification confirmation request with the challenge issuance receipt previously submitted by the verification terminal. If the challenge digest matches, the terminal identifier is consistent, and the current time is still within the 20-second time window, the challenge is deemed valid. If no corresponding challenge issuance receipt is found, or the terminal identifier in the receipt is inconsistent with the current request, or the challenge has expired, the server refuses to generate an intent lock to prevent forged or expired challenges from entering the verification process.

[0074] After completing signature verification and challenge validity checks, the server further checks whether the session sequence number corresponding to the device binding identifier remains incremented. The session sequence number in the most recent successful revocation record for this bound device is 152, and the session sequence number carried in this request is 153. The server compares the historical maximum sequence number with the current sequence number, and only continues processing if 153 is strictly greater than 152 and the one-time challenge has not yet been used. If the current sequence number is less than or equal to 152, the server considers there to be a risk of historical data replay, old session duplication, or forged incrementing relationships, and therefore refuses to generate an intent lock.

[0075] Once all the above verifications pass, the server generates an intent lock associated with this verification session and binds this intent lock to the signature field identifier. Subsequently, the server registers the signature field identifier as already occupied by the current intent lock and sends second confirmation data for network transmission to the verification terminal. The second confirmation data includes at least the session identifier, challenge association information, signature field verification result, and intent lock identifier. Because the signature field identifier is uniquely bound to this intent lock, even if an attacker intercepts this signature message, they cannot migrate it to other sessions or other benefit scenarios, thus reducing the risk of signature reuse across sessions.

[0076] While the server-side processing is underway, the mobile terminal generates first confirmation data for near-field transmission based on this verification session and sends it to the verification terminal via the near-field link. The first confirmation data includes at least session association information corresponding to the session identifier and the one-time challenge. After receiving the first and second confirmation data within a defined window, the verification terminal performs a consistency comparison of the session association information in both. Only when the session identifier, challenge association field, and signature field are consistent is the actual verification performed and the result reported. The first confirmation data arrives at the verification terminal 1.8 seconds after the challenge is generated, and the second confirmation data arrives 2.6 seconds after the challenge is generated. Both are within a 20-second valid window; therefore, the verification terminal performs this rights verification after completing the comparison.

[0077] To illustrate the latency performance, let the arrival latency of the first confirmation data on the near-field side be . The arrival delay of the second confirmation data on the network side is Because the verification terminal can only complete the verification after both confirmation data have arrived, the completion time for this verification is delayed. It can be represented as:

[0078] in, s, s. Substituting the values, we get:

[0079] This shows that although dual-channel confirmation via near-field link and network link is introduced, the verification terminal can obtain all execution conditions within 2.6 seconds, which is significantly faster than the 20-second challenge validity window. This indicates that the scheme can maintain a high response speed while enhancing security. Figure 2 The time of one-time challenge generation, the arrival time of the first confirmation data on the near side (1.8s), and the arrival time of the second confirmation data on the network side (2.6s) are marked in a timeline. The acceptable reimbursement window range is represented by a shaded area within the 20s challenge validity window. The time when the reimbursement execution conditions are met is determined by the slower of the two confirmations.

[0080] To further illustrate the processing effectiveness in a real-world business scenario, we analyzed the rights and interests redemption status of this service point on a specific business day. The total number of redemption requests that day was 1200, of which 1140 were successfully redeemed, 30 were rejected due to exceeding the 20-second validity window, 18 were rejected due to abnormal session sequence numbers, and 12 were rejected due to signature verification failures. Let the total number of requests be... Successful sales volume was The success rate It can be represented as:

[0081] Will and Substitute the values ​​and calculate the ratio first:

[0082] Recalculate the success rate:

[0083] The results show that even with the introduction of multiple security checks, a 95% reconciliation success rate can still be maintained in high-frequency scenarios, balancing efficiency and availability. Figure 3 Using a waterfall chart, starting with a total of 1200 requests, 30 requests were rejected due to expired challenges, 18 requests due to abnormal session sequence numbers, and 12 requests due to failed signature verification. The final result was 1140 successful cancellations, thus visually demonstrating the impact of various rejection reasons on the success rate.

[0084] Next, we analyze the effectiveness of anomaly interception. Let the number of challenges rejected due to expiration be... The number of sessions rejected due to abnormal sequence numbers is The number of signature verification failures that resulted in rejection was [number missing]. The total number of security interceptions It can be represented as:

[0085] , , After substituting the values, first calculate the sum of the first two items, which is 48. Then, when checking the third item, it should be noted that the difference between the total number of requests and the number of successful requests is 60. Therefore, 30 requests are due to expired challenges, 18 are due to abnormal session sequence numbers, and 12 are due to failed signature verification. The total number of these three types of exceptions is 60.

[0086] The calculation shows that the system intercepted 60 abnormal or high-risk requests in a single business day. Among these, expired challenges blocked delayed submissions of old challenges, abnormal session sequence numbers blocked replays of historical session data, and failed signature verification blocked requests from unbound devices. The multi-layered protection was quite effective. To illustrate the relative proportions of the three types of anomaly interceptions from a strength perspective, Figure 4 Using a polar coordinate bar chart, the number of rejections for each type is represented by the radius, and the number and percentage are marked on the outer ring, making the differences in the blocking strength of 30 expired challenges, 18 abnormal session numbers, and 12 failed signature verifications more intuitive.

[0087] After the verification terminal completes the verification and reports the result to the server, the server marks the one-time challenge as used and the intent lock as used simultaneously, and registers the associated signature field identifier as unusable. At this point, the verification session is closed. Even if an attacker subsequently intercepts network or near-field packets during this verification process, they cannot initiate a new valid verification request using the same challenge, intent lock, or signature field identifier. Especially under the condition that the verification terminal simultaneously requires the first confirmation data to be consistent with the second confirmation data, isolated replay of any single-sided data will not meet the execution conditions, thus significantly improving the overall reliability of the system.

[0088] Compared to traditional rights verification methods that rely solely on single-channel network confirmation or local near-field triggering, this embodiment employs a process where the verification terminal initiates a one-time challenge, the server verifies the challenge issuance receipt, the mobile terminal completes the signature as a bound device, the server verifies the monotonically increasing session sequence number and generates an intent lock, and the verification terminal performs a dual-channel consistency comparison. This approach not only prevents unbound devices from impersonating the user but also suppresses forged challenges, challenge replays, and signature reuse across sessions. Furthermore, it keeps the verification completion latency to within 2.6 seconds.

[0089] Example 2: In a business environment, a redemption terminal for rights verification is deployed. When a user enters the near-field communication (NFC) coverage area of ​​this terminal with their mobile device, the terminal detects the mobile device entering the NFC range, generates a one-time challenge, and sends it to the mobile device via the NFC link. Simultaneously, a session identifier is assigned to this redemption session, and a timer for a limited window is started. The timer is set to 15 seconds to ensure that the one-time challenge and subsequent dual-channel confirmation are completed within the valid time, thereby reducing the risks associated with delayed submission and cross-session splicing.

[0090] Upon receiving a one-time challenge, the mobile terminal does not directly generate confirmation data but instead initiates a secure interaction process. The mobile terminal explicitly displays the verification terminal identifier or rights identifier on the interface, allowing users to intuitively identify the target to be verified. Simultaneously, the mobile terminal generates a short digest prompt code derived from the one-time challenge and presents this code alongside the aforementioned verification terminal identifier or rights identifier. A 4-digit short digest prompt code is used; this code is a string of numbers valid only for this challenge and serves as the basis for on-site human-machine consistency verification.

[0091] After seeing the verification terminal identifier or rights identifier and the 4-digit short summary code on the mobile terminal interface, the user checks the short summary code against the information displayed or prompted by the on-site verification terminal. Confirmation is only performed on the mobile terminal when the user confirms the short summary code matches. The user completes this manual confirmation within 2 seconds of receiving the one-time challenge, thus limiting the manual confirmation process to a controllable timeframe and preventing delayed confirmation after the code has been remotely relayed.

[0092] After user confirmation, the mobile terminal generates an presence confirmation identifier associated with this verification session. This presence confirmation identifier is linked to the session identifier, one-time challenge, verification terminal identifier or benefits identifier, and short summary prompt code, ensuring it only represents the verification intent explicitly confirmed by the user in this session. The presence confirmation identifier contains a single confirmation sequence number under the same session identifier, used to express the uniqueness of this confirmation action within this session. The single confirmation sequence number increments from 1; the sequence number corresponding to this manual confirmation is 1.

[0093] The mobile terminal writes the presence confirmation identifier into the first confirmation data and sends it to the verification terminal via the near-field link. Simultaneously, the mobile terminal sends the presence confirmation identifier or its summary to the server via the network, enabling the server to participate in the verification of the presence confirmation identifier and provide the verification terminal with network-side confirmation evidence. This dual-channel transmission method allows the verification terminal to obtain direct credentials of the user's presence confirmation on the local near-field side, while simultaneously obtaining a verifiable verification field generated by the server on the network side, thereby reducing the possibility of unilateral data forgery or replay.

[0094] After receiving a verification confirmation request containing the presence confirmation identifier or its summary, the server parses the current verification session context based on the session identifier and verifies the consistency of the binding relationship between the presence confirmation identifier and the one-time challenge, verification terminal identifier or benefit identifier, and short summary prompt code. Upon successful verification, the server writes the corresponding verification field into the second confirmation data and records that the single-confirmation sequence number is currently in an available state. The verification field is used by the verification terminal to confirm the validity of the presence confirmation identifier on the network side, and the available sequence number status is set to "used" after verification to prevent the presence confirmation identifier from being replayed or split and reused.

[0095] Within a 15-second window, the verification terminal receives first confirmation data from the near-field side and second confirmation data from the server. It then extracts the presence confirmation identifier from the first confirmation data and the verification field from the second confirmation data, comparing the session identifier, challenge association information, and the consistency of the verification field. Only when the first confirmation data, second confirmation data, and verification field match and are all within the specified window does the verification terminal perform the rights verification and report the verification result to the server. The first confirmation data arrives at the verification terminal at 1.5 seconds, and the second confirmation data arrives at the verification terminal at 2.1 seconds, both significantly earlier than the 15-second window limit.

[0096] After receiving the successful verification result reported by the verification terminal, the server changes the single confirmation sequence number from an available state to a used state and marks the associated record of the presence confirmation identifier corresponding to the sequence number in this session as completed, thereby preventing subsequent replay attempts on the same presence confirmation identifier. If an attacker attempts to reuse the presence confirmation identifier or its digest in a subsequent session, the server will refuse to generate the corresponding valid verification field because the sequence number has been used and the bound session identifier, one-time challenge, and short digest hint code do not match. The verification terminal will also be unable to obtain consistent first and second confirmation data simultaneously, thus achieving closed-loop suppression of replay and split reuse.

[0097] To illustrate the completion time of the verification process under dual-channel coordination, let the arrival delay of the first confirmation data on the near-field side be . The arrival delay of the second confirmation data on the network side is Because the verification terminal can only perform verification after both confirmations have been received, the completion time for this verification is [not specified]. It can be represented as:

[0098] in s, s. After substituting the values, we first compare the two, and the larger one is 2.1s, thus obtaining:

[0099] Therefore, it can be seen that after introducing explicit user confirmation and dual-channel verification, the reconciliation terminal can still complete the execution condition aggregation in 2.1 seconds, significantly less than the 15-second timeframe, thus balancing reliability and reconciliation efficiency. To better illustrate the key timing relationship between manual confirmation and dual-channel confirmation within the timeframe, Figure 5 Within a 15-second timeframe, the system indicates the completion of user manual confirmation within 2 seconds, the arrival of the first confirmation from the near-field side within 1.5 seconds, and the arrival of the second confirmation from the network side within 2.1 seconds. The system also indicates the fulfillment of the verification execution conditions by displaying the arrival time of both channels.

[0100] To illustrate the effect of short digest prompt code consistency verification on suppressing erroneous cancellations, let's assume the erroneous cancellation rate before introducing prompt codes for manual verification is... The error rate after introducing prompt codes and manual confirmation is [missing information]. Under the same statistical caliber, without the introduction of confirmation codes, if 20 out of 1000 cancellations are mistakenly cancelled, then:

[0101] After introducing a consistency verification code, if 4 out of 1000 reconciliations are incorrectly reconciled, then:

[0102] Further set the percentage decrease in the erroneous write-off rate as follows: ,but:

[0103] After substituting, first calculate the difference. Then calculate the ratio. =0.8, finally obtained The results show that, through explicit user confirmation and short digest prompt code consistency verification, the false cancellation rate decreased by 80%, effectively reducing the probability of users triggering cancellations before the correct cancellation object or the prompt code being misused, leading to false cancellations. To visually demonstrate the change in the false cancellation rate before and after the introduction of short digest prompt code consistency verification, Figure 6 The error cancellation rates of 2.0% and 0.4% are compared, and the downward trend of the error cancellation rate is indicated by arrows.

[0104] Within a certain statistical period, to further demonstrate the synergistic effect of serial number replay protection, a total of 1500 revocation requests were processed. Of these, 18 were actively cancelled by users due to inconsistent short digest prompt codes, 12 were rejected by the server because it determined that the serial number had already been used in a single confirmation, and 12 were rejected because the 15-second window limit was exceeded. Ultimately, 1458 revocations were successfully completed. The above data shows that the 18 requests with inconsistent prompt codes were actively blocked by users before revocation execution; the 12 requests with already used serial numbers were explicitly rejected by the server; and the 12 requests exceeding the window limit were blocked by time constraints. This creates a coordinated protection mechanism between the user side, the server side, and the time constraint side, maintaining a closed statistical scope. To facilitate the demonstration of the closed-loop path of the 1500 requests within the statistical period, Figure 7 Using a waterfall chart format, starting with a total of 1500 requests, the chart sequentially deducts 18 requests canceled due to inconsistent prompt codes, 12 requests rejected due to used serial numbers, and 12 requests rejected due to exceeding the 15-second window limit. At the end, a summary point is marked to indicate that 1458 requests were successfully completed and cleared. This visually demonstrates the request flow under the combined effect of prompt code consistency confirmation, serial number replay prevention, and time limit constraints.

Claims

1. A method for rapid rights verification based on near-field communication, applied to user mobile terminals, verification terminals, and servers, characterized in that... include: After the verification terminal detects that the mobile terminal has entered the near-field communication range, it generates a one-time challenge and sends it via the near-field communication. When the mobile terminal is validly logged into the account and the device is bound to the account, it sends the challenge, session identifier, device binding identifier and rights identifier to the server via the network to form a verification confirmation request. After verifying the session identifier, device binding identifier, and the validity of the challenge, the server generates an intent lock associated with the verification session and forms second confirmation data for network transmission, which is then sent to the verification terminal. The mobile terminal generates first confirmation data associated with the verification session for near-field transmission and sends it to the verification terminal via near-field transmission. The first confirmation data includes at least session association information corresponding to the session identifier and the one-time challenge. When the verification terminal obtains the first confirmation data and the second confirmation data within the limited window and the session association information is consistent, it performs verification and reports the result. The server sets the challenge and intent lock to be used to prevent duplicate verification.

2. The method for rapid rights revocation based on near-field communication according to claim 1, characterized in that... The device binding identifier is determined by the public key digest corresponding to the non-derivative key generated by the mobile terminal in the protected environment; when the mobile terminal sends a verification confirmation request to the server, it signs the data containing the one-time challenge, session identifier and rights identifier and sends it with the request; the server verifies the signature before generating the intent lock to confirm that the login device that initiated the request is the binding device.

3. The method for rapid rights cancellation based on near-field communication according to claim 1, characterized in that... After generating a one-time challenge, the verification terminal sends a challenge issuance receipt to the server. The receipt includes at least the terminal identifier, challenge summary, and issuance time. The server determines the challenge is valid and generates an intent lock only if the challenge in the verification confirmation request matches the receipt and is within a limited window; otherwise, it refuses to generate the lock.

4. The method for rapid rights cancellation based on near-field communication according to claim 1, characterized in that... The first confirmation data includes an presence confirmation identifier generated by the mobile terminal after receiving a one-time challenge and completing a confirmation through secure interaction, and is bound to the session identifier and the one-time challenge; the mobile terminal sends the presence confirmation identifier or its summary to the server via the network along with the verification confirmation request; the server writes a verification field corresponding to the presence confirmation identifier into the second confirmation data; the verification terminal performs verification only when the first confirmation data, the second confirmation data, and the verification field correspond to each other and are within a limited window.

5. The method for rapid rights cancellation based on near-field communication according to claim 2, characterized in that... After the mobile terminal generates the non-exportable key, it sends a key generation certificate output by the protected environment to the server. The server verifies the key generation certificate before accepting the device binding identifier. After successful verification, the server determines the device binding identifier using the corresponding public key digest.

6. The method for rapid rights cancellation based on near-field communication according to claim 2, characterized in that... The one-time challenge includes a verification terminal identifier and a monotonically increasing session sequence number; when the mobile terminal signs, the terminal identifier and session sequence number are overwritten together; after the signature verification is successful, the server verifies that the session sequence number is increasing relative to the device binding identifier and that the one-time challenge has not been used, otherwise it refuses to generate an intent lock.

7. The method for rapid rights cancellation based on near-field communication according to claim 2, characterized in that... Before generating the intent lock, the server sends a signature field identifier corresponding to the current verification session to the mobile terminal. The sending is done via the network to the mobile terminal or forwarded by the verification terminal. When the mobile terminal sends a verification confirmation request, it adds the signature field identifier to the signature data; when the server verifies the signature, it checks whether the signature field identifier is consistent with the verification session, and binds the signature field identifier to the intent lock and sets it to be used, so as to restrict the reuse of the signature across sessions or across rights.

8. The method for rapid rights cancellation based on near-field communication according to claim 4, characterized in that... The secure interaction includes displaying the verification terminal identifier or rights identifier on the mobile terminal; the mobile terminal generates the presence confirmation identifier only after the user confirms, and binds the presence confirmation identifier to the verification terminal identifier or rights identifier.

9. The method for rapid rights cancellation based on near-field communication according to claim 4, characterized in that... The presence confirmation identifier includes a single confirmation sequence number under the same session identifier and is written into the first confirmation data; the server records the availability status of the sequence number in the verification field of the second confirmation data, and sets the sequence number as used after the verification report is submitted, so as to prevent the presence confirmation identifier from being replayed or split and reused.

10. The method for rapid rights cancellation based on near-field communication according to claim 8, characterized in that... When the mobile terminal explicitly displays the verification terminal identifier or rights identifier, it also displays a short summary prompt code derived from the one-time challenge; the user confirmation includes a confirmation of the consistency of the short summary prompt code, and the presence confirmation identifier is bound to the short summary prompt code.

Images