An offline food delivery lock control method, terminal, and system based on hardware trust chain

Abstract

This invention relates to the field of intelligent logistics lock control and information security technology, and in particular discloses an offline food delivery lock control method, terminal, and system based on a hardware trust chain. The method includes: a background process generating an offline authorization token based on the hardware fingerprint and dynamic key of the food delivery terminal; in the offline state of the food delivery terminal, the ordering terminal collects the biometric features of the person ordering the food and generates a verification request; the food delivery terminal decrypts the token using the hardware fingerprint and verifies the biometric binding relationship in a local trusted execution environment; after successful verification, the food delivery terminal generates a one-time temporary unlocking command and sends it to the electronic seal lock; the electronic seal lock verifies the signature and validity period of the temporary command in its local security chip and then executes the unlocking. This invention achieves strong binding between unlocking permissions and specific terminals and specific personnel in offline scenarios, eliminating the risk of abuse and replay of offline authorization credentials.

Description

Technical Field

[0001] This invention relates to the field of intelligent logistics lock control and information security technology, and in particular to an offline food delivery lock control method, terminal and system based on a hardware trust chain. Background Technology

[0002] In food delivery and on-demand delivery scenarios, electronic seal locks are widely used to prevent unauthorized opening of packages during delivery. Existing mainstream solutions (such as those described in patent number CN202010740759.9) rely on a real-time network connection between a backend server and the terminal to achieve remote authorization and status monitoring of the lock. However, network blind spots often occur at actual delivery destinations (such as basements, high-rise buildings, and elevator cars), preventing users from unlocking the locks in a timely manner and severely impacting delivery efficiency and user experience.

[0003] To address the offline unlocking issue, existing technologies (such as those described in patent number CN202010378694.8) have proposed offline solutions where the locker itself stores the retrieval voucher locally in a meal locker scenario. In this solution, the fixed locker acts as the computing entity, responsible for voucher generation and verification. However, for electronic seal locks that move with the package, due to cost, size, and power consumption limitations, the lock itself has weak computing power and lacks a complex user interface, making it impossible to directly adopt the locker solution.

[0004] On the other hand, even if the unlock code is simply pre-stored in the food delivery terminal and sent to the lock when offline (as described in patent number CN202210719856.9), there are still security risks: once the unlock code is maliciously obtained or the food delivery terminal is operated by others, the lock can be opened at will without leaving a trace in an offline environment, making it impossible to effectively trace the responsible party and creating a regulatory loophole.

[0005] Therefore, there is an urgent need for a technical solution that can both adapt to the hardware limitations of mobile locks and ensure the security and traceability of offline unlocking behavior.

[0006] Application content

[0007] This invention addresses the challenge of achieving a secure, traceable, and non-abuse-prone offline unlocking control method under conditions of limited electronic seal lock hardware resources and unstable last-mile delivery networks. It proposes an offline food delivery lock control method, terminal, and system based on a hardware trust chain. The responsibility for offline unlocking authorization verification is transferred to the delivery terminal (e.g., the rider's smartphone). The secure execution environment (TEE) and hardware fingerprint of the delivery terminal are used as trust anchors to construct a chain-like trust transfer system: "back-end → delivery terminal → ordering terminal → electronic seal lock." Simultaneously, the orderer's biometrics are introduced as a secondary verification factor, combined with dynamic keys, time stamps, and geofencing to achieve strong authentication and fine-grained access control under offline conditions.

[0008] The technical solution of this invention is implemented as follows:

[0009] An offline food delivery lock control method based on a hardware trust chain is applied to a system including a back-end management system, electronic seal locks, food delivery terminals, and ordering terminals. The method includes:

[0010] When connected to the network, the back-end management system responds to order association requests by obtaining the unique identifier of the electronic seal lock bound to the order and the hardware fingerprint information of the designated delivery terminal.

[0011] The background management system generates a dynamic unlocking key corresponding to the unique identifier of the electronic seal lock, and encrypts the dynamic unlocking key using the hardware fingerprint information to generate and issue an offline authorization token bound to the terminal hardware.

[0012] When the food delivery terminal is connected to the network, the back-end management system sends the offline authorization token to the secure storage area of ​​the food delivery terminal.

[0013] When the food delivery terminal is disconnected from the back-end management system, the food delivery terminal receives an offline unlocking verification request sent by the ordering terminal. The offline unlocking verification request includes at least the biometric (such as facial) verification data of the current orderer collected by the ordering terminal, and constructs a verification request and sends it to the food delivery terminal.

[0014] The food delivery terminal calls the offline authorization token, uses the hardware fingerprint information stored in the terminal to decrypt the offline authorization token in a trusted execution environment, obtains the dynamic unlocking key, and verifies whether the biometric verification data is consistent with the identity binding information pre-stored in the offline authorization token;

[0015] If the verification matches, the food delivery terminal generates a one-time temporary unlocking command based on the dynamic unlocking key and the current timestamp, and sends the one-time temporary unlocking command to the target electronic seal lock via near-field communication (such as Bluetooth).

[0016] The electronic seal lock receives the one-time temporary unlocking command, uses the root key preset in the internal security chip to verify the validity of the dynamic unlocking key and timestamp, and drives the unlocking mechanism to perform the unlocking action after the verification is successful.

[0017] The food delivery terminal records the operation log of this unlocking event in local secure storage, and uploads the operation log to the back-end management system after restoring network connection with the back-end management system, thus completing the traceability loop.

[0018] Furthermore, the offline authorization token also includes permission constraints, which include the authorized geofence range and / or the authorized valid time window;

[0019] Before or after verifying the biometric verification data, the food delivery terminal further obtains the current location information and the current time information. When the current location information exceeds the authorized geofence range or the current time information exceeds the authorized valid time window, the unlocking process is terminated and an abnormal alarm record is generated.

[0020] Furthermore, the food delivery terminal generates a one-time temporary unlocking instruction by: the food delivery terminal combining the dynamic unlocking key with the current timestamp and the current operation sequence number, performing a hash operation on the combined data using the dynamic unlocking key to generate a message authentication code, and using the message authentication code as part of the one-time temporary unlocking instruction.

[0021] Furthermore, the biometric verification data of the current person ordering food collected by the ordering terminal is at least one of the following: facial feature vectors collected by the ordering terminal through a camera, fingerprint feature data collected by a fingerprint sensor, or voiceprint feature data collected by a microphone.

[0022] Furthermore, the food delivery terminal decrypts the offline authorization token in a trusted execution environment using the hardware fingerprint information stored in the terminal. This includes: the food delivery terminal decrypting the offline authorization token using a pre-stored private key or symmetric key corresponding to the hardware fingerprint information in a trusted execution environment built with ARM TrustZone or an independent security chip.

[0023] Furthermore, when the backend management system generates the offline authorization token, it also includes: the backend management system associating and storing the orderer's identity binding information sent by the ordering terminal with the offline authorization token; the orderer's identity binding information includes the orderer's registered biometric template index or the orderer's unique account identifier.

[0024] Furthermore, the electronic seal lock uses a root key preset in the internal security chip to verify the validity of the dynamic unlocking key and the timestamp, including: the security chip of the electronic seal lock uses a preset symmetric root key to decrypt and verify the received dynamic unlocking key, and checks whether the deviation between the timestamp and the local clock is within the allowable range; if the deviation exceeds the threshold, the lock is refused to be opened and the abnormal state is recorded.

[0025] The present invention also discloses an offline food delivery lock control system based on a hardware trust chain, including a back-end management system, an electronic seal lock, a food delivery terminal, and an ordering terminal. The components of the system work together to achieve the method described above.

[0026] The present invention also discloses a computer-readable storage medium having stored thereon computer program instructions that, when executed by a processor, implement the steps of the method described above.

[0027] This invention also discloses a food delivery terminal device, including a processor, a memory, a near-field communication module, and a secure execution environment module. When the processor executes the computer program stored in the memory, it performs the following steps:

[0028] Q1. Receive and store offline authorization tokens issued by the backend management system while connected to the network. The offline authorization token is encrypted data generated based on the dynamic unlocking key of the target electronic seal lock and the hardware fingerprint information of this terminal.

[0029] Q2. In the offline state, receive the offline unlock verification request initiated by the ordering terminal, the request containing the biometric verification data of the person ordering the food;

[0030] Q3. Within the secure execution environment module, the offline authorization token is decrypted and its permissions are verified using the hardware fingerprint information of this terminal.

[0031] Q4. After successful verification, a one-time temporary unlocking command is generated and sent to the target electronic seal lock via a short-range communication module;

[0032] Q5. Record the operation log of offline unlocking events, and upload the operation log to the backend management system after the network is restored.

[0033] By adopting the above technical solution, the beneficial effects of the present invention are as follows:

[0034] 1. The offline authorization token is bound to the fingerprint of the food delivery terminal hardware. Even if the token file is copied to other devices, it cannot be decrypted and used, thus preventing the transfer and abuse of authorization credentials.

[0035] 2. The unlocking action requires both "possession of the designated food delivery terminal" and "biometric matching of the person placing the order" to be met simultaneously, achieving dual verification of "physical evidence + personal evidence" and greatly improving security.

[0036] 3. When verifying the electronic seal lock command, the timestamp and signature are checked, which effectively prevents replay attacks that intercept legitimate unlocking commands and reuse them.

[0037] 4. The food delivery terminal acts as an offline monitoring recorder, recording detailed data such as unlocking time, location, and verification method, thus filling the management blind spots during network outages.

[0038] 5. Complex permission verification logic is offloaded to the more powerful food delivery terminal, and the electronic seal lock only needs to perform lightweight decryption verification, which reduces the hardware cost and power consumption of the lock. Attached Figure Description

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

[0040] Figure 1 This is a schematic diagram of the system architecture and interactions of each component of the present invention;

[0041] Figure 2 This is the main flowchart of the method of the present invention;

[0042] Figure 3 This is a sequence diagram of the offline authorization token generation and issuance process;

[0043] Figure 4 This is a flowchart of the authentication and unlocking signaling between the ordering terminal, the delivery terminal, and the electronic seal lock in an offline environment;

[0044] Figure 5 This is a block diagram of the internal module structure of the food delivery terminal of the present invention. Detailed Implementation

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

[0046] like Figure 1 As shown, an offline food delivery lock control method based on hardware trust chain is proposed. This method runs in a system consisting of a background management system 100, a food delivery terminal 200, an ordering terminal 300, and an electronic seal lock 400.

[0047] The back-end management system 100 is deployed on a cloud server and is responsible for order management, lock management, key generation, and authorization credential distribution. The back-end management system 100 maintains the following databases:

[0048] Lock information database: Stores information such as the unique identifier (lock number) of each electronic seal lock, the root key index pre-set in the security chip, and the current status (in use / idle);

[0049] Order information database: Stores information such as order number, orderer account ID, pre-registered biometric template index (or template hash value) of the orderer, and assigned deliveryman ID;

[0050] Terminal information database: Stores the hardware fingerprint information of the food delivery terminal 200. The hardware fingerprint information is reported by the food delivery terminal 200 during registration, and the back-end management system 100 binds and stores it with the deliveryman ID.

[0051] The food delivery terminal 200 is a smartphone used by delivery personnel, running the Android operating system (version 8.0 or higher, supporting ARM TrustZone technology). The delivery terminal 200 has a dedicated application for delivery personnel (Delivery App) installed. The delivery terminal 200 includes the following key hardware and software modules:

[0052] Processor and memory: Run the Android system and applications;

[0053] Near-field communication module: including Bluetooth 5.0 module and NFC module, used for short-range data exchange with electronic seal lock 400 and ordering terminal 300;

[0054] Secure Execution Environment Module: In this embodiment, a trusted execution environment (TEE) built using ARM TrustZone technology is used. An independent, lightweight trusted application runs in this TEE environment to perform security-sensitive operations such as decryption of offline authorization tokens, biometric comparison, and generation of temporary unlocking instructions. The TEE environment is isolated from the ordinary operating system, so even if the ordinary operating system is compromised by malicious programs, the data and operations within the TEE remain secure.

[0055] Hardware fingerprint acquisition module: Used to acquire the hardware fingerprint of this terminal. The hardware fingerprint uses a combination of at least one of the following: IMEI (International Mobile Equipment Identity), MEID (Mobile Equipment Identity), Android ID, device serial number, and Wi-Fi MAC address. In this embodiment, when the food delivery app is launched for the first time, it concatenates the IMEI and Android ID and calculates the SHA-256 hash value, and uploads this hash value as the hardware fingerprint to the backend management system 100.

[0056] The ordering terminal 300 is a smartphone used by the person ordering food. It has an ordering client application installed and is equipped with a camera and Bluetooth module, enabling it to collect the person's biometric data. In this embodiment, the biometric data is a facial feature vector. The ordering terminal 300 collects the person's facial image during registration, extracts the feature vector template, and uploads the template hash value to the backend management system 100 to bind it to the person's account.

[0057] The Electronic Seal Lock 400 is a reusable, portable smart lock used to lock the opening of takeout packaging bags.

[0058] The electronic seal lock 400 contains the following electronic components:

[0059] Bluetooth Low Energy module: used to receive unlock commands;

[0060] Security chip: NXP A71CH or Infineon OPTIGA Trust series models are available. The security chip internally stores a unique root key K. root The root key is written by the lock manufacturer at the factory and kept synchronized with the key management service of the background management system 100. The security chip can perform operations such as encryption / decryption and message authentication code verification based on symmetric keys.

[0061] Microcontroller: Used to drive the unlocking mechanism (such as a micro motor or solenoid valve) and coordinate the data interaction between the Bluetooth module and the security chip;

[0062] Real-time clock: Provides a time reference for the electronic seal lock 400 to verify the timeliness of instructions.

[0063] The following is combined Figures 2 to 4 The flowchart below provides a detailed explanation of the specific steps of the method in this embodiment.

[0064] Step S1: The backend management system generates and issues an offline authorization token.

[0065] When the delivery person arrives at the restaurant to pick up the food, the restaurant uses the store manager to bind the order to be delivered to an available electronic seal lock 400. The binding process is as follows: the store manager reads the lock number LockID of the electronic seal lock 400 via RFID or Bluetooth, selects the corresponding order number OrderID via the touch screen, and then uploads the association relationship (LockID, OrderID) to the back-end management system 100.

[0066] S101: After receiving the (LockID, OrderID) association request, the backend management system 100 queries the order information database to obtain the assigned delivery person ID corresponding to the order, and then queries the terminal information database to obtain the hardware fingerprint H of the delivery terminal 200 held by the delivery person. Device (i.e., the SHA-256 hash value of the combination of IMEI and Android ID).

[0067] S102: The backend management system 100 calls the key generation service to generate a dynamic unlock key DK for this order. The DK is a 128-bit or 256-bit random string (e.g., using an AES-128 key). The DK has single-use or limited-use characteristics, and its lifespan only covers this delivery task.

[0068] S103: The backend management system queries the order information database to obtain the account ID of the person who placed the order, and then obtains the hash value H of the pre-registered facial feature template of that person. FaceTemplate Optionally, obtain the unique identifier (UID) of the person who placed the order.

[0069] S104: The backend management system 100 constructs the data structure for the offline authorization token OToken. In this embodiment, OToken is a JSON-formatted structure, which is encrypted and distributed as a binary file.

[0070] S105: The back-end management system 100 uses the hardware fingerprint H of the food delivery terminal 200. Device The JSON plaintext data is used as the encryption key to encrypt the data, generating an offline authorization token (OToken) in ciphertext state. The specific encryption algorithm used is AES-256-GCM to ensure data confidentiality and integrity. The encryption process can be represented as: OToken = AES GCM Encrypt(H Device Plaintext JSON ).

[0071] S106: When the food delivery terminal 200 is connected to the network (usually when picking up food), the backend management system 100 sends the generated OToken to the food delivery app running on the food delivery terminal 200 via mobile network or Wi-Fi. After receiving the OToken, the food delivery app stores it in a secure storage area protected by the Android Keystore system, or directly in a secure file system associated with the TEE environment, ensuring that ordinary application layers cannot directly read or tamper with it.

[0072] Step S2: The food delivery terminal receives the unlock verification request from the ordering terminal when it is offline.

[0073] When the delivery person delivers the food to the destination, both the delivery terminal 200 and the ordering terminal 300 are in an area without mobile network signal coverage (such as a basement), and neither of them can establish a connection with the back-end management system 100.

[0074] S201: The customer opens the ordering app on the ordering terminal 300, selects the corresponding pending order, and clicks the "Offline Unlock" button. The ordering app prompts the customer to perform facial recognition verification.

[0075] S202: The ordering terminal 300 accesses the system camera to capture a frontal facial image of the person ordering food. The ordering app uses a lightweight facial feature extraction algorithm (such as Google's FaceNet or algorithms in the open-source library OpenCV) to extract a 128-dimensional or 512-dimensional floating-point feature vector FV from the captured image.current To reduce the amount of data transmitted and protect privacy, food ordering apps use FV (Functional Data Entry). current Perform a hash operation to obtain the current face feature hash value H. FaceCurrent = SHA-256(FV current ).

[0076] S203: The ordering terminal 300 turns on Bluetooth and searches for nearby Bluetooth devices broadcasting a specific service UUID. When the delivery terminal 200's delivery app enters offline delivery mode, it will activate a Bluetooth Peripheral Mode and broadcast a packet containing the specific service UUID. After the ordering terminal 300 discovers the device, it establishes a Bluetooth connection.

[0077] S204: The ordering terminal 300 constructs an offline unlocking verification request message and sends it to the delivery terminal 200 via the established Bluetooth connection. This request message includes the following fields: order number (optional, used by the delivery terminal to confirm the corresponding token), and the hash value H of the current orderer's facial features. FaceCurrent Request initiation timestamp.

[0078] Step S3: The food delivery terminal performs permission verification in the TEE environment.

[0079] S301: After receiving the offline unlock verification request, the food delivery app of the food delivery terminal 200 submits the request data and the corresponding OToken ciphertext to the trusted application running in the TEE environment.

[0080] S302: In a TEE environment, trusted applications first use the hardware fingerprint H securely stored on this terminal. Device Decrypt the OToken ciphertext.

[0081] The decryption process is as follows: Plaintext JSON = AES GCM Decrypt(H Device (OToken). Upon successful decryption, a plaintext data structure containing the dynamic unlock key DK and various constraints is obtained.

[0082] S303: Trusted applications perform the following local permission checks on the validity of the token:

[0083] Time validity verification: Read the secure clock within the TEE environment and obtain the current time T. current Check T current Check if the token is within the [start, end] range defined by the token timestamp field. If not, terminate the process and return the error code "Token expired".

[0084] Usage count verification: Read the number of times the token has been used from the local record. If the number of uses is greater than or equal to the maximum number of uses, the process terminates and returns the error code "Token usage limit reached".

[0085] Geofence verification (optional): The delivery terminal 200 obtains its current location information via GPS or base station positioning (the GPS module can still work independently even when offline). It checks whether the distance between the current location and the center point of the token geofence is less than the radius defined by the geofence. If it exceeds the range, the process terminates and returns the error code "Current location is not in the authorized area".

[0086] Biometric binding verification: The decrypted binding face hash value (i.e., H) is used to verify the binding. FaceTemplate ) and the face hash value (i.e., H) carried in the request message FaceCurrent The system will compare the two. If they match, the person placing the order is considered to have passed identity verification; if they do not match, the process will terminate and return the error code "Face verification failed".

[0087] S304: If all the above checks pass, the trusted application will decrement the maximum number of uses in the token by 1 (or increment the number of uses in the local record by 1) and update the storage.

[0088] Step S4: The food delivery terminal generates and sends a one-time temporary unlock command.

[0089] S401: After successful verification, trusted applications within the executable environment can read the dynamically unlocked key DK obtained through decryption. To prevent replay attacks, the trusted application needs to generate a one-time temporary unlock command. The specific generation process is as follows:

[0090] Get the timestamp T1 (accurate to the second) of the current executable environment's security clock;

[0091] Maintain a monotonically increasing operation sequence number Seq (increment by 1 each time an instruction is generated);

[0092] Calculate the message authentication code (MAC) as follows: MAC = HMAC-SHA256(DK, LockID || T1 || Seq). Here, HMAC-SHA256 is a hash-based message authentication code algorithm, DK is the key, and the concatenation of LockID, T1, and Seq represents the message content.

[0093] Construct a one-time temporary unlock command data packet: {LockID, DK, T1, Seq, MAC}.

[0094] S402: The trusted application returns the constructed data packet to the food delivery app in the ordinary operating system through a secure channel. The food delivery app then sends the data packet to the electronic seal lock 400 via the Bluetooth communication module using a Bluetooth GATT write signature.

[0095] S403: Simultaneously, the food delivery app of the delivery terminal 200 records the operation log of this unlocking event in local secure storage. The operation log includes the following fields:

[0096] Token id: The unique identifier of the OToken used;

[0097] Lock id: Target electronic seal lock number;

[0098] timestamp: Unlock command generation time T1;

[0099] location: latitude and longitude of the current location;

[0100] Auth method: Verification method (in this example, "face recognition");

[0101] result: Validation result ("Passed").

[0102] The log is stored in encrypted form in the local database and marked as "pending synchronization".

[0103] Step S5: Verify the electronic seal lock command and execute the unlocking.

[0104] S501: After receiving a one-time temporary unlock command data packet, the Bluetooth module of the electronic seal lock 400 forwards it to the microcontroller. The microcontroller then sends the key fields in the data packet to the security chip for processing.

[0105] S502: The security chip performs the following validity verifications:

[0106] Clock skew check: The security chip reads its own real-time clock T local Calculate |T1 - T local The absolute value of the key is used to determine if the difference exceeds a preset allowable threshold (e.g., 5 minutes), in which case unlocking is refused. This mechanism prevents intercepted historical commands from being replayed.

[0107] Dynamic unlock key verification: The security chip uses an internally preset root key K. root To verify the DK, in one implementation of this embodiment, the backend management system 100 uses K simultaneously when generating the DK. rootThe DK is encrypted or signed to generate a DK verification credential that is issued along with the OToken; however, to reduce the lock's dependence on the backend, another preferred approach is that the DK itself is a credential generated by the K. root Encrypted data, or DK and K root There is a pre-defined mathematical relationship (e.g., DK = PRF(K)). root (LockID || OrderID)); The security chip verifies the legitimacy of the DK by decrypting or recalculating and comparing it; This embodiment uses the second method: the DK is generated by the backend management system 100 using the root key K. root The hash result of the concatenated value (LockID, OrderID, validity period) is truncated. After receiving DK, the security chip uses its internal K... root The expected DK value is recalculated using the LockID stored locally and compared with the received DK.

[0108] Message authentication code verification: The security chip uses the verified DK as the key to recalculate the MAC value of the received (LockID, T1, Seq) concatenated data and compare it with the received MAC. If they match, it proves that the instruction was indeed generated by the food delivery terminal 200 holding the correct DK, and that the data has not been tampered with during transmission.

[0109] S503: If all the above verifications pass, the security chip sends an "unlock permission" signal to the microcontroller. The microcontroller drives the motor drive circuit to control the unlocking mechanism, causing the electronic seal lock 400 to switch from the locked state to the unlocked state. At the same time, the electronic seal lock 400 returns a "unlock successful" confirmation message to the food delivery terminal 200 via Bluetooth.

[0110] S504: If any verification fails, the security chip records the abnormal event (e.g., "MAC verification failed," "clock deviation too large"), and controls the lock body to remain locked via the microcontroller, while simultaneously returning the corresponding error status code to the food delivery terminal 200. After receiving the error status code, the food delivery terminal 200 will also record the reason for the unlocking failure in its operation log.

[0111] Step S6: After the food delivery terminal restores the network, upload the operation log;

[0112] S601: After the delivery person completes the delivery and returns to an area with network coverage, the delivery terminal 200 re-establishes a network connection with the back-end management system 100.

[0113] S602: When the food delivery app detects that the network connection has been restored, it automatically starts the log synchronization service. This service reads all operation logs marked as "pending synchronization" in the local storage, packages them, and uploads them to the backend management system 100 via the HTTPS security protocol.

[0114] S603: After receiving the operation log, the back-end management system 100 associates and stores it with the corresponding order record according to the token id or lock id. Thus, even if there is a network blind spot during the delivery process, the back-end management system 100 can still obtain a complete unlocking behavior record, realizing a traceable closed loop for offline unlocking behavior.

[0115] Example 2: Offline Food Delivery Lock Control System Based on Fingerprint Recognition

[0116] This embodiment has the same basic process as Embodiment 1, the difference being:

[0117] The biometric data collected by the ordering terminal 300 is fingerprint data. The person ordering food enters their fingerprint through the fingerprint sensor of the ordering terminal 300, the ordering terminal 300 extracts the fingerprint feature template, and uploads the template hash value to the backend as identity binding information.

[0118] During the offline unlocking verification stage, the ordering terminal 300 collects the fingerprint feature data of the person ordering the food, calculates the hash value, and sends it to the delivery terminal 200 for comparison and verification.

[0119] Other steps, including offline authorization token generation, TEE environment decryption, temporary instruction generation and verification, are consistent with those in Example 1.

[0120] Example 3: Offline Food Delivery Lock Control System Based on Voiceprint Recognition

[0121] This embodiment has the same basic process as Embodiment 1, the difference being:

[0122] The biometric data collected by the ordering terminal 300 is voiceprint data. The person ordering food registers their voiceprint by reading a preset phrase. The ordering terminal 300 extracts the voiceprint feature template and uploads the template hash value to the backend as identity binding information.

[0123] During the offline unlocking verification stage, the ordering terminal 300 prompts the person ordering the food to read a randomly generated string of numbers, collects the audio and extracts the voiceprint feature hash value, and sends it to the food delivery terminal 200 for comparison and verification.

[0124] Example 4: Specific Implementation of Food Delivery Terminal Equipment

[0125] like Figure 5As shown, the food delivery terminal 200 includes a processor 210, a memory 220, a short-range communication module 230, a secure execution environment module 240, a positioning module 250, and a display module 260.

[0126] in:

[0127] The processor 210 executes the computer program stored in the memory 220 to implement the steps performed by the food delivery terminal 200 in the above method;

[0128] Memory 220 includes a general storage area and a secure storage area, the secure storage area being used to store offline authorization tokens and operation logs;

[0129] The near-field communication module 230 includes a Bluetooth communication unit and an NFC communication unit.

[0130] The secure execution environment module 240 is an executable environment based on ARM TrustZone, in which trusted applications running are responsible for performing security operations such as encryption, decryption, and verification.

[0131] The positioning module 250 is a GPS module used to obtain geographical location information.

[0132] Display module 260 is a touch screen used to display information such as delivery tasks and unlocking status.

[0133] This application's offline food delivery lock control method utilizes the trusted execution environment and hardware fingerprint of the delivery terminal as a trust anchor point. It transfers the responsibility for authorization verification in offline mode from the restricted electronic seal lock to the more powerful delivery terminal, and combines this with the orderer's biometric binding to achieve strong dual authentication of "physical evidence + human verification" in an offline environment. Simultaneously, it effectively defends against replay attacks through mechanisms such as one-time temporary commands and timestamp verification, and achieves full traceability of the delivery process through post-event synchronization of operation logs. Compared with existing technologies, this invention significantly improves the overall security of the system while ensuring the convenience of offline unlocking, and has high industrial application value.

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

Claims

1. A hardware chain-based offline meal delivery lock control method applied to a system comprising a background management system, an electronic seal lock, a meal delivery terminal and an order terminal, characterized in that, The method includes: The back-end management system responds to the order association request by obtaining the unique identifier of the electronic seal lock bound to the order and the hardware fingerprint information of the designated delivery terminal; The background management system generates a dynamic unlocking key corresponding to the unique identifier of the electronic seal lock, and encrypts the dynamic unlocking key using the hardware fingerprint information to generate an offline authorization token; When the food delivery terminal is connected to the network, the back-end management system sends the offline authorization token to the secure storage area of ​​the food delivery terminal. When the food delivery terminal is disconnected from the back-end management system, the food delivery terminal receives an offline unlocking verification request sent by the ordering terminal. The offline unlocking verification request includes at least the biometric verification data of the current orderer collected by the ordering terminal. The food delivery terminal calls the offline authorization token, uses the hardware fingerprint information stored in the terminal to decrypt the offline authorization token in a trusted execution environment, obtains the dynamic unlocking key, and verifies whether the biometric verification data is consistent with the identity binding information pre-stored in the offline authorization token; If the verification matches, the food delivery terminal generates a one-time temporary unlocking command based on the dynamic unlocking key and the current timestamp, and sends the one-time temporary unlocking command to the target electronic seal lock via short-range communication; The electronic seal lock receives the one-time temporary unlocking command, uses the root key preset in the internal security chip to verify the validity of the dynamic unlocking key and timestamp, and drives the unlocking mechanism to perform the unlocking action after the verification is successful. The food delivery terminal records the operation log of this unlocking event in local secure storage, and uploads the operation log to the backend management system after restoring network connection with the backend management system.

2. The offline food delivery lock control method based on hardware trust chain according to claim 1, characterized in that, The offline authorization token also includes permission constraints, which include the authorized geofence range and / or the authorized valid time window; Before or after verifying the biometric verification data, the food delivery terminal further obtains the current location information and the current time information. When the current location information exceeds the authorized geofence range or the current time information exceeds the authorized valid time window, the unlocking process is terminated and an abnormal alarm record is generated.

3. The offline food delivery lock control method based on hardware trust chain according to claim 1, characterized in that, The food delivery terminal generates a one-time temporary unlocking command, which includes: the food delivery terminal combining the dynamic unlocking key with the current timestamp and the current operation sequence number, using the dynamic unlocking key to perform a hash operation on the combined data to generate a message authentication code, and using the message authentication code as part of the one-time temporary unlocking command.

4. The offline food delivery lock control method based on hardware trust chain according to claim 1, characterized in that, The biometric verification data of the current person ordering food collected by the ordering terminal is at least one of the following: facial feature vectors collected by the ordering terminal through a camera, fingerprint feature data collected by a fingerprint sensor, or voiceprint feature data collected by a microphone.

5. The offline food delivery lock control method based on hardware trust chain according to claim 1, characterized in that, The food delivery terminal decrypts the offline authorization token in a trusted execution environment using the hardware fingerprint information stored in the terminal. This includes: the food delivery terminal decrypts the offline authorization token using a pre-stored private key or symmetric key corresponding to the hardware fingerprint information in a trusted execution environment built with ARM TrustZone or an independent security chip.

6. The offline food delivery lock control method based on hardware trust chain according to claim 1, characterized in that, When the back-end management system generates an offline authorization token, it further includes: the back-end management system associating and storing the orderer's identity binding information sent by the ordering terminal with the offline authorization token; the orderer's identity binding information includes the orderer's registered biometric template index or the orderer's unique account identifier.

7. The offline food delivery lock control method based on hardware trust chain according to claim 1, characterized in that, The electronic seal lock uses a root key preset in the internal security chip to verify the validity of the dynamic unlocking key and the timestamp. This includes: the security chip of the electronic seal lock uses a preset symmetric root key to decrypt and verify the received dynamic unlocking key, and checks whether the deviation between the timestamp and the local clock is within the allowable range; if the deviation exceeds the threshold, the lock is refused to be opened and the abnormal state is recorded.

8. An offline food delivery lock control system based on a hardware trust chain, characterized in that, The system includes a back-end management system, an electronic seal lock, a food delivery terminal, and an ordering terminal. The components of the system work together to implement an offline food delivery lock control method based on a hardware trust chain as described in any one of claims 1 to 7.

9. A computer-readable storage medium having computer program instructions stored thereon, characterized in that, When the computer program instructions are executed by the processor, they implement the steps of the offline food delivery lock control method based on a hardware trust chain as described in any one of claims 1 to 7.

10. A food delivery terminal device, comprising a processor, a memory, a near-field communication module, and a secure execution environment module, characterized in that, When the processor executes the computer program stored in the memory, it performs the following steps: Q1. Receive and store the offline authorization token issued by the background management system while connected to the network. The offline authorization token is encrypted data generated based on the dynamic unlocking key of the target electronic seal lock and the hardware fingerprint information of this terminal. Q2. In the offline state, receive the offline unlock verification request initiated by the ordering terminal, the request containing the biometric verification data of the person ordering the food; Q3. Within the secure execution environment module, the offline authorization token is decrypted and its permissions are verified using the hardware fingerprint information of this terminal. Q4. After successful verification, a one-time temporary unlocking command is generated and sent to the target electronic seal lock via a short-range communication module; Q5. Record the operation log of offline unlocking events, and upload the operation log to the backend management system after the network is restored.

Images