Warehouse business data encryption system and method based on hybrid encryption architecture

Abstract

The application belongs to the field of data encryption, and particularly relates to a warehouse business data encryption system and method based on a hybrid encryption architecture, which comprises a key negotiation module, a encryption framing module, a multi-factor authentication module and an abnormal response module. The key negotiation module generates a session key bound to a job task through an improved Diffie-Hellman protocol based on the equipment fingerprint of a four-way vehicle and the public key of a warehouse gateway, and automatically destroys the session key after the task is completed. The encryption framing module adopts AES-GCM-256 to encrypt the business data subject, RSA-2048 to encrypt the session key, and SHA-256 to add a hash value and real-time position coordinates to assemble a ciphertext data frame. The multi-factor authentication module performs three-way identity verification through the equipment fingerprint, ECDSA digital signature and warehouse area identifier, and dynamically switches the session multiplexing and segmented authentication strategies according to the comparison result of the network round-trip delay and the preset threshold. The abnormal response module accumulates the number of consecutive hash verification failures, and triggers key renegotiation and generates an event record when the threshold is reached. The application guarantees the end-to-end security of warehouse business data, and takes into account the encryption efficiency and authentication reliability.

Description

Technical Field

[0001] This invention belongs to the field of data encryption, and in particular relates to a data encryption system and method for warehousing operations based on a hybrid encryption architecture. Background Technology

[0002] In the field of intelligent warehousing and logistics, four-way shuttles, as core handling equipment, need to perform high-frequency handling and retrieval operations in the high-density storage aisles of automated storage and retrieval systems. During operation, they require continuous real-time data interaction with the warehouse management system, rack sensors, sorting terminals, and other four-way shuttles. The interaction content includes scheduling instructions, cargo information, location coordinates, and inventory data. The confidentiality, integrity, and authenticity of such business data directly determine the continuity of warehousing operations and asset security. Since four-way shuttles are constantly moving and switching between regions, communication links frequently hop between wireless networks and different access nodes, resulting in significant dynamic and heterogeneous security threats to data transmission.

[0003] In existing technologies, a common approach is to directly employ a single symmetric encryption algorithm to protect the communication link. For example, a pre-shared key is deployed between the four-way vehicle and the warehouse management system, and all business data is transmitted using AES symmetric encryption. This type of approach has high encryption and decryption efficiency in closed, static network environments. However, in warehouse scenarios with a large number of four-way vehicles and frequent network entry and exit, updating and distributing the pre-shared key becomes extremely difficult. Furthermore, if a single key is leaked, the communication security of the entire system collapses.

[0004] Another approach focuses on the preprocessing stage before data encryption. By normalizing and feature mapping the original business data, it enhances the consistency and resistance to attacks during the encryption process. Chinese patent CN109684860B discloses a data encryption method and apparatus based on business relationships. In this method, key nodes are established for each logical unit number (LUN) in the storage system. When a service is activated, the key parameters of the primary LUN are synchronized to the key nodes of the secondary LUNs, allowing different LUNs with established business relationships to share the storage key, thereby reducing redundant encryption and decryption processing during data interaction within the storage system. This approach solves the problem of key synchronization and processing efficiency between different logical storage units within the storage system. However, its key synchronization mechanism relies on predefined business relationships and a centralized key management server, and does not address the dynamic negotiation and periodic updating of session keys on the wireless transmission link. In warehousing environments where vehicles frequently move across areas and network access nodes constantly switch, the trust relationships between communication endpoints are temporary and dynamically changing. Pre-established business associations and static key sharing strategies cannot adapt to this dynamic end-to-end security requirement.

[0005] Another approach attempts to achieve dynamic key generation and adaptive adjustment of security strategies by introducing a quantum random number generator and network situational awareness. Chinese patent CN120090883B discloses a business data encryption method and system using quantum encryption. This method constructs a fixed time window, acquires key metadata and network pulse information of each bank's business data within that window, generates a point cloud set, generates a persistent graph through topological data analysis, extracts statistics to calculate decision factors, determines the key length based on the sensitivity coefficient and decision factors of each business data, and calls a quantum random number generator to generate a unique key for each business data within the current time window. This method achieves dynamic decoupling of encryption strategies and network resources, and can flexibly adjust the key length according to network conditions. However, the calculation of its decision factors relies on the statistical characteristics of financial business metadata such as transaction timestamps, transaction amounts, and user identifiers. The generated persistent graph and topological features only reflect the macroscopic statistical patterns of business traffic. In the four-way vehicle warehouse scheduling scenario, the data packets transmitted in a single transmission are discrete scheduling instructions and location coordinates, which do not have the statistical characteristics of continuous financial transaction flow. Furthermore, the invocation of its quantum random number generator uses the unique identifier of the bank's business data as a seed, and does not provide technical means to verify the authenticity of the four-way vehicle device itself under a decentralized certificate system.

[0006] Therefore, the technical problem that the existing technology urgently needs to solve is how to build an end-to-end data transmission protection mechanism that balances encryption and decryption efficiency and key distribution security during the continuous movement of four-way vehicles and the switching of work tasks, without relying on centralized certificate queries and business flow statistical characteristics. This mechanism should simultaneously meet the real-time encryption and decryption requirements of massive scheduling instructions, dynamic identity verification of communication endpoints in mobile scenarios, and key synchronization compatibility between multi-brand equipment and heterogeneous warehousing systems, and overcome the defects of static keys being easily leaked, asymmetric encryption computation overhead being large, and cross-system authentication systems being inconsistent. Summary of the Invention

[0007] To address the shortcomings of existing technologies, this invention proposes a warehousing business data encryption system and method based on a hybrid encryption architecture, including a key negotiation module, an encryption framing module, a multi-factor authentication module, and an anomaly response module. The key negotiation module uses the device fingerprint of the four-way vehicle and the public key of the warehousing gateway to generate a session key bound to the job task via an improved Diffie-Hellman protocol, which is automatically destroyed upon task completion. The encryption framing module uses AES-GCM-256 to encrypt the business data body, RSA-2048 to encrypt the session key, and assembles it into a ciphertext data frame by adding a SHA-256 hash value and real-time location coordinates. The multi-factor authentication module performs triple identity verification using device fingerprint, ECDSA digital signature, and warehousing area identifier, and dynamically switches between session reuse and segmented authentication strategies based on the comparison result of network round-trip latency and a preset threshold. The anomaly response module accumulates the number of consecutive hash verification failures, triggering key renegotiation and generating an event log when a threshold is reached. This invention ensures end-to-end security of warehousing business data while balancing encryption efficiency and authentication reliability.

[0008] To achieve the above objectives, the present invention provides the following technical solution:

[0009] A warehouse data encryption system based on a hybrid encryption architecture includes:

[0010] The key negotiation module is configured to: extract the device fingerprint of the four-way vehicle, the device fingerprint consisting of a hardware serial number and operating system characteristics; use the device fingerprint and the public key of the warehouse gateway as input to generate a session key through an improved Diffie-Hellman protocol, associate the session key with the current job task identifier, and destroy the session key in response to a change in the job task identifier or a job completion signal;

[0011] The encryption framing module is configured to: encrypt the service data body with the AES-GCM-256 algorithm, encrypt the session key with the RSA-2048 algorithm, calculate the SHA-256 hash value of the encrypted service data body, and assemble the real-time position coordinates of the four-way vehicle, the encrypted service data body, the encrypted session key, and the SHA-256 hash value into a ciphertext data frame and send it.

[0012] The multi-factor authentication module is configured to: receive the encrypted data frame, extract the device fingerprint to verify hardware legitimacy, verify the ECDSA digital signature to confirm the authenticity of the data source, extract the warehouse area identifier to confirm the compliance of the access scenario; obtain the network round-trip latency, maintain session reuse when the network round-trip latency is less than a preset latency threshold, and perform segmented authentication and breakpoint resumption on unconfirmed data fragments when the network round-trip latency is greater than or equal to the preset latency threshold;

[0013] The exception response module is configured to: accumulate the number of consecutive failures of SHA-256 hash verification within a statistical period; when the number of consecutive failures reaches a preset threshold, trigger the renegotiation of the session key and generate an event record containing the device fingerprint and the number of consecutive failures.

[0014] Specifically, the device fingerprint also includes at least one of the following: the MAC address of the four-way vehicle's network card, the unique identifier of the security chip, or the endorsement key of the Trusted Platform Module (TPM); the hardware serial number includes at least one of the following: the CPU serial number, the motherboard serial number, or the storage module serial number; the generation of the session key through the improved Diffie-Hellman protocol includes:

[0015] Perform a hash operation on the extracted device fingerprint to obtain a device fingerprint digest;

[0016] On the elliptic curve domain, the four-way vehicle generates a temporary private key, and performs a dot product operation on the temporary private key using the elliptic curve base points to obtain a temporary public key for the four-way vehicle, and sends the temporary public key for the four-way vehicle to the warehouse gateway.

[0017] The warehouse gateway generates a temporary private key and performs a dot product operation on the temporary private key using the elliptic curve base points to obtain a temporary public key, which is then sent to the four-way vehicle.

[0018] Specifically, generating session keys via the improved Diffie-Hellman protocol also includes:

[0019] The four-way vehicle performs a dot product operation between its temporary private key and the temporary public key of the gateway to obtain a first shared secret, and the warehouse gateway performs a dot product operation between its temporary private key and the temporary public key of the four-way vehicle to obtain a second shared secret.

[0020] The first shared secret and the second shared secret are concatenated with the device fingerprint digest to obtain the first concatenated secret and the second concatenated secret;

[0021] The first concatenated secret and the second concatenated secret are input into the hash-based message authentication code key derivation function to generate the session key, so that the session key is simultaneously bound to the shared secret and the device fingerprint of the four-way vehicle.

[0022] Specifically, the SHA-256 hash value is calculated for the encrypted business data body, including:

[0023] The main body of the business data to be transmitted and the currently valid session key are taken as inputs and sent to the first parallel branch and the second parallel branch respectively.

[0024] In the first parallel branch, the business data subject and the session key are taken as input, encrypted by the AES-GCM-256 algorithm, and the business data ciphertext, the first authentication tag and the initialization vector are output. The business data ciphertext is then hashed independently to output the first hash value.

[0025] Specifically, calculating the SHA-256 hash value for the encrypted business data subject also includes:

[0026] In the second parallel branch, it is executed synchronously with the first parallel branch. It takes the session key and the preset warehouse gateway public key as input, encrypts them using the RSA-2048 algorithm, outputs the session key ciphertext, and independently performs a hash operation on the session key ciphertext to output the second hash value.

[0027] The encrypted business data, the first authentication tag, the initialization vector, the first hash value, the encrypted session key, and the second hash value are taken as input, assembled into an encrypted data frame according to a preset frame structure, and output and sent to the receiving end.

[0028] Specifically, in response to a change in the job task identifier or a job completion signal, the session key is destroyed, including:

[0029] A session key usage counter is set, with an initial value of zero. Each time the encryption framing module starts to perform an encryption operation on a frame of service data body with the current session key, the session key usage counter is incremented by one. Each time the encryption operation on a frame of service data body is completed and the ciphertext data frame is output, the session key usage counter is decremented by one.

[0030] Receive a task identifier change signal or task completion signal issued by the warehouse management system, read the current value of the session key usage counter, and determine whether the current value is equal to zero.

[0031] Specifically, in response to a change in the job task identifier or a job completion signal, destroying the session key further includes:

[0032] If the current value is not equal to zero, it is determined that the current session key still has at least one frame of business data in the encryption process. The job task identifier change signal or job completion signal is temporarily stored, and the session key usage counter is continuously polled until the current value is equal to zero. Then, a session key destruction command is sent to the hardware security module to overwrite the session key register with all zeros and release the association between the current session key and the job task identifier.

[0033] If the current value is equal to zero, it is determined that there is no encryption operation in transit for the current session key. A session key destruction command is immediately sent to the hardware security module to overwrite the session key register with all zeros and release the association between the current session key and the job task identifier.

[0034] Specifically, the device fingerprint is extracted to verify hardware legitimacy, the ECDSA digital signature is verified to confirm the authenticity of the data source, and the warehouse area identifier is extracted to confirm the compliance of the access scenario, including:

[0035] The receiving end extracts the sender's warehouse area identifier field, the sender's device fingerprint field, and the sender's ECDSA digital signature field from the frame header extension field of the encrypted data frame;

[0036] The sender's storage area identifier is compared byte by byte with the currently accessed storage area identifier preset in the receiver's hardware security module. If the comparison result is inconsistent, the encrypted data frame is discarded and the authentication process is terminated.

[0037] If the comparison results are consistent, the sender device fingerprint is compared byte by byte with each registered device fingerprint stored in the registered device fingerprint database. If the comparison results of the sender device fingerprint with all registered device fingerprints are inconsistent, the encrypted data frame is discarded and the authentication process is terminated.

[0038] Specifically, the process includes extracting the device fingerprint to verify hardware legitimacy, verifying the ECDSA digital signature to confirm the authenticity of the data source, and extracting the warehouse area identifier to confirm the compliance of the access scenario. It also includes:

[0039] If the comparison result between the sender's device fingerprint and a registered device fingerprint is consistent, the registered ECDSA verification public key associated with that registered device fingerprint is read from the registered device fingerprint database. A byte string formed by concatenating all remaining fields in the ciphertext data frame after excluding the sender's ECDSA digital signature field is used as the message to be verified. A SHA-256 hash value is calculated for the message to be verified. Using the SHA-256 hash value, the sender's ECDSA digital signature, and the registered ECDSA verification public key as inputs, an ECDSA digital signature verification operation is performed. If the signature verification result is invalid, the ciphertext data frame is discarded and a signature verification failure event record is generated; if the signature verification result is valid, the ciphertext data frame is submitted to the decryption process.

[0040] The data encryption method for warehouse operations based on a hybrid encryption architecture includes:

[0041] Extract the device fingerprint of the four-way vehicle, which consists of a hardware serial number and operating system characteristics; use the device fingerprint and the public key of the warehouse gateway as input to generate a session key through an improved Diffie-Hellman protocol, and associate the session key with the current job task identifier; in response to a change in the job task identifier or a job completion signal, destroy the session key.

[0042] The service data body is encrypted with the AES-GCM-256 algorithm, the session key is encrypted with the RSA-2048 algorithm, the SHA-256 hash value is calculated on the encrypted service data body, and the real-time position coordinates of the four-way vehicle, the encrypted service data body, the encrypted session key and the SHA-256 hash value are assembled into a ciphertext data frame and sent.

[0043] The system receives the encrypted data frame, extracts the device fingerprint to verify hardware legitimacy, verifies the ECDSA digital signature to confirm the authenticity of the data source, and extracts the warehouse area identifier to confirm the compliance of the access scenario. It also obtains the network round-trip latency, maintains session reuse when the network round-trip latency is less than a preset latency threshold, and performs segmented authentication and breakpoint resumption on unconfirmed data fragments when the network round-trip latency is greater than or equal to the preset latency threshold.

[0044] The cumulative number of consecutive failures of SHA-256 hash verification within the statistical period is counted. When the number of consecutive failures reaches a preset threshold, the session key is renegotiation is triggered, and an event record containing the device fingerprint and the number of consecutive failures is generated.

[0045] Compared with the prior art, the beneficial effects of the present invention are:

[0046] This invention forcibly binds the lifecycle of the session key to the job task identifier through the key negotiation module, automatically destroying it upon task completion, fundamentally eliminating the risk of leakage caused by long-term session key residency; the encryption framing module adopts a hybrid architecture of AES-GCM-256 symmetric encryption of the business data body and RSA-2048 asymmetric encryption of the session key, while embedding SHA-256 hash values ​​and real-time location coordinates, enabling the data to have tamper-proof and replay attack resistance capabilities while maintaining high throughput encryption efficiency; the multi-factor authentication module verifies the hardware legitimacy of the device through device fingerprint verification, the authenticity of the data source through ECDSA digital signature verification, and the warehouse... The combination of regional identifier verification, access scenario compliance, and other three elements effectively blocks unauthorized devices from impersonating others to access the system. By dynamically switching session reuse and segmented authentication strategies through comparison of network round-trip latency with preset thresholds, authentication and retransmission are only performed on unconfirmed fragments during network fluctuations, significantly reducing the impact of authentication interruptions on transmission continuity. The anomaly response module automatically initiates key renegotiation and synchronizes event records based on the number of consecutive hash verification failures, enabling the system to quickly isolate threats and retain traceable audit evidence when subjected to continuous attacks. Thus, a high level of security, low-latency response, and strong fault tolerance are simultaneously achieved on the end-to-end transmission link of warehouse business data. Attached Figure Description

[0047] Figure 1 This is a block diagram of a warehouse business data encryption system based on a hybrid encryption architecture, as described in Embodiment 1 of the present invention.

[0048] Figure 2 This is a logical diagram of a warehouse business data encryption system based on a hybrid encryption architecture, as described in Embodiment 1 of the present invention.

[0049] Figure 3 The following is a logical diagram of how the improved Diffie-Hellman protocol is used to generate session keys in Embodiment 2 of the present invention.

[0050] Figure 4 This is a flowchart of the warehousing business data encryption method based on a hybrid encryption architecture, which is an embodiment of the present invention. Detailed Implementation

[0051] Example 1

[0052] Please see Figure 1 One embodiment of the present invention provides a warehouse business data encryption system based on a hybrid encryption architecture, applied to a four-way vehicle, a warehouse gateway, and a warehouse management system, comprising:

[0053] The key negotiation module is configured to: extract the device fingerprint of the four-way vehicle, the device fingerprint consisting of a hardware serial number and operating system characteristics; generate a session key using the device fingerprint and the public key of the warehouse gateway as input through an improved Diffie-Hellman protocol, associate the session key with the current job task identifier, and destroy the session key in response to a change in the job task identifier or a job completion signal; the device fingerprint also includes at least one of the four-way vehicle's network card MAC address, a unique identifier of the security chip, or an endorsement key of the Trusted Platform Module (TPM); the hardware serial number includes at least one of the CPU serial number, motherboard serial number, or storage module serial number;

[0054] The encryption framing module is configured to: encrypt the service data body with the AES-GCM-256 algorithm, encrypt the session key with the RSA-2048 algorithm, calculate the SHA-256 hash value of the encrypted service data body, and assemble the real-time position coordinates of the four-way vehicle, the encrypted service data body, the encrypted session key, and the SHA-256 hash value into a ciphertext data frame and send it.

[0055] The multi-factor authentication module is configured to: receive the encrypted data frame, extract the device fingerprint to verify hardware legitimacy, verify the ECDSA digital signature to confirm the authenticity of the data source, extract the warehouse area identifier to confirm the compliance of the access scenario; obtain the network round-trip latency, maintain session reuse when the network round-trip latency is less than a preset latency threshold, and perform segmented authentication and breakpoint resumption on unconfirmed data fragments when the network round-trip latency is greater than or equal to the preset latency threshold;

[0056] The exception response module is configured to: accumulate the number of consecutive failures of SHA-256 hash verification within a statistical period; when the number of consecutive failures reaches a preset threshold, trigger the renegotiation of the session key and generate an event record containing the device fingerprint and the number of consecutive failures.

[0057] Example 2

[0058] Please see Figure 3 It should be further noted that this embodiment generates the session key through an improved Diffie-Hellman protocol, including:

[0059] A101. Perform a hash operation on the extracted device fingerprint to obtain a device fingerprint digest, specifically:

[0060] After the A1011 four-way vehicle's built-in encryption chip completes its power-on self-test, it executes the device fingerprint raw data acquisition process. Specifically, the encryption chip sequentially reads the CPU serial number register and the motherboard serial number register via the internal bus to obtain the CPU serial number string and the motherboard serial number string. The CPU serial number string is a 32-bit hexadecimal character sequence, and the motherboard serial number string is also a 32-bit hexadecimal character sequence. The encryption chip obtains the operating system version number string and the kernel compilation identifier string through the system call interface. The format of the operating system version number string is major version number, dot character, minor version number, dot character, and revision number string concatenated in sequence. The format of the kernel compilation identifier string is kernel version number string, hyphen, and compilation sequence number string concatenated in sequence. The encryption chip concatenates the above four strings according to a preset concatenation order and a preset delimiter. The preset concatenation order is CPU serial number string, motherboard serial number string, operating system version number string, and kernel compilation identifier string. The preset delimiter is a vertical bar character. After concatenation, the raw device fingerprint string is obtained. The encryption chip writes the original string of the device fingerprint into a secure random access memory buffer inside the chip, and the address space of this buffer is physically isolated from the general data processing area of ​​the encryption chip.

[0061] The A1012 encryption chip performs a SHA-256 hash operation on the original device fingerprint string in the security buffer. Specifically, the encryption chip reads the byte length of the original device fingerprint string, multiplies the byte length by eight to obtain the bit length of the message, and checks whether the remainder after taking the bit length of the message modulo 512 is equal to 448. If it is not equal to 448, a binary 1 bit is appended to the end of the message, followed by a variable number of binary 0 bits, until the remainder after taking the bit length of the message modulo 512 equals 448. If the remainder after taking the bit length of the message modulo 512 is already equal to 448, the above padding operation is performed again, padding with a binary 1 bit and the necessary number of binary 0 bits, and then padding the length at the next 512-bit boundary. After padding, the encryption chip appends the 64-bit unsigned integer length of the original message to the end of the padded message, making the final message's total bit length a multiple of 512. The encryption chip divides the padded message into multiple message blocks in 512-bit increments, sequentially labeling them as the first message block, the second message block, and so on until the last message block.

[0062] A1013. The encryption chip sequentially performs SHA-256 compression function iterative operations on the divided message blocks. Specifically, the encryption chip initializes eight 32-bit working variables, assigning them the values ​​of the eight initial hash constants specified by the SHA-256 algorithm. That is, the first working variable is assigned the value 0x6a09e667, the second working variable is assigned the value 0xbb67ae85, the third working variable is assigned the value 0x3c6ef372, the fourth working variable is assigned the value 0xa54ff53a, the fifth working variable is assigned the value 0x510e527f, the sixth working variable is assigned the value 0x9b05688c, the seventh working variable is assigned the value 0x1f83d9ab, and the eighth working variable is assigned the value 0x5be0cd19. The encryption chip reads each 512-bit message block sequentially according to the message block order. It expands the currently read 512-bit message block into sixty-four 32-bit message words according to the message scheduling specified by the SHA-256 algorithm. The current values ​​of eight working variables are copied into eight temporary variables. These eight temporary variables are then updated round by round with the sixty-four message words of the current message block according to the sixty-four rounds of iteration specified by the SHA-256 algorithm. Each round of updates uses the constant value corresponding to the sixty-four 32-bit round constants specified by the SHA-256 algorithm. After sixty-four rounds of iteration, the eight temporary variables are added modulo 2 to the eight working variables respectively. The addition result is used as the initial value of the eight working variables when processing the next message block. After all message blocks have been processed, the encryption chip concatenates the final eight working variables in the order of the first to the eighth working variables. Each working variable is output as four bytes in big-endian format. The concatenated result is a 256-bit output, which is the device fingerprint digest.

[0063] A1014. The encryption chip stores the generated device fingerprint digest in a one-time programmable memory area within the chip. Once written, this one-time programmable memory area can only be read by the key negotiation module inside the encryption chip via the internal hardware bus; external processors, applications, and communication interfaces are not allowed to access it in any form. During the four-way vehicle device registration phase, the warehouse gateway obtains the device fingerprint digest of the four-way vehicle through a secure channel injected offline via a physical connection. It then establishes an association mapping between the device fingerprint digest and the four-way vehicle's device identifier, storing this association mapping record in the warehouse gateway's registered device fingerprint database. The registered device fingerprint database is stored in the protected storage area of ​​the warehouse gateway's hardware security module.

[0064] In this embodiment, the basis for using the SHA-256 hash operation to map the original device fingerprint string to a device fingerprint digest is as follows: First, the original device fingerprint string is composed of four variable-length string fields concatenated with vertical bar characters. The CPU serial number string and motherboard serial number string have character values ​​limited to the hexadecimal character set, the operating system version number string alternates between numeric and dot characters, and the kernel compilation identifier string contains mixed alphanumeric characters. The character frequency distribution of each field exhibits significant non-uniformity and a field-specific structural pattern. Directly using this original device fingerprint string as input to the subsequent key derivation function will result in a structural bias in the input space of the key derivation function. This structural bias, after compression and expansion operations by the key derivation function, may introduce statistical correlation between the bits of the output key, reducing the effective entropy value and resistance to exhaustive search of the session key. Second, through the SHA-256 hash operation, an original device fingerprint string of arbitrary length can be mapped to a fixed 256-bit device fingerprint digest. Regardless of the string length of each of the four fields, the final output device fingerprint digest length is constant at 256 bits, eliminating the influence of variable input length on the input interface format of the subsequent key derivation function. Third, the avalanche effect of the SHA-256 algorithm ensures that flipping any bit in the original device fingerprint string will result in a flip of approximately 128 bits in the device fingerprint digest. This means that each bit in the device fingerprint digest is uniformly dependent on all the input bits of the original device fingerprint string, and the output bit string follows a uniform distribution, eliminating the non-uniformity of the input character distribution. Fourth, the one-wayness of the SHA-256 algorithm guarantees that for any given device fingerprint digest output, an attacker cannot computationally recover the corresponding original device fingerprint string. The required computational complexity is on the order of 2 to the power of 256. Even if the device fingerprint digest appears outside the trusted environment due to security logging or auditing needs, an attacker cannot use it to forge the original device fingerprint string to pass subsequent hardware legitimacy verification.

[0065] A102. On the elliptic curve domain, the four-way vehicle generates a temporary private key, and performs a dot product operation on this temporary private key using the elliptic curve base points to obtain a temporary public key for the four-way vehicle. The temporary public key for the four-way vehicle is then sent to the warehouse gateway, specifically as follows:

[0066] Before initiating the key negotiation process, the A1021 four-way vehicle first checks whether a session key negotiation record with a status of "negotiation in progress" already exists in the hardware security module. If it exists, it terminates the current request and returns an error code to the caller, indicating that there is an incomplete negotiation process. If it does not exist, it writes the "negotiation in progress" status identifier into the session status register of the hardware security module, sets the session identifier as the unique identifier for this key negotiation, obtains the current job task identifier from the upper-layer application and records it in the session record table, and completes the initialization of the negotiation process.

[0067] A1022. The four-way vehicle invokes a true random number generator within the hardware security module. This generator acquires at least one physical noise signal from a hardware entropy source, including voltage jitter, oscillator phase noise, or thermal noise. After analog-to-digital conversion and entropy extraction algorithms, it obtains an original entropy value sequence. This sequence is then input into a hash-based deterministic random bit generator conforming to the NIST SP 800-90A standard to generate a 256-bit candidate random number. In this embodiment, the true random number generator within the hardware security module first acquires analog noise signals from physical entropy sources (such as ring oscillators or thermal noise). It then uses a built-in high-speed analog-to-digital converter (ADC) to perform equal-interval sampling and quantization at a preset sampling rate (e.g., 100MHz) and quantization bit width (e.g., 12 bits), outputting an original digital quantized sample sequence arranged in a time series. Subsequently, the entropy extraction algorithm adopts the online health testing and debiasing process specified in the NIST SP800-90B standard: The original samples undergo bit-level debiasing using a von Neumann corrector, i.e., conditional probability filtering of adjacent sample bits, retaining only combinations of "01" or "10" and discarding "00" or "11" to eliminate the systematic DC bias introduced by the inherent bias of the physical entropy source; simultaneously, combined with repetition counting and adaptive scaling tests, the Hamming weight distribution and run length of the samples are monitored in real time, eliminating abnormal sample blocks that do not meet the uniform distribution requirement. The effective entropy bits after the above correction and filtering are accumulated and compressed by an entropy compressor based on a cryptographic hash function (such as SHA-256), outputting a fixed-length (e.g., 256 bits) and statistically uniform original entropy value sequence. This sequence serves as the input seed for a deterministic random bit generator (such as HMAC_DRBG or CTR_DRBG) conforming to the NIST SP 800-90A standard, ensuring that subsequently generated random numbers possess verifiable cryptographic security.

[0068] The hardware security module performs a non-zero check on the candidate random number: It performs a bitwise logical OR operation between all 256 bits of the candidate random number and the string of all zero bits. If every bit of the result is zero, the candidate random number is determined to be all zeros, discarded, and regenerated until it passes the non-zero check. After passing the non-zero check, the hardware security module reads the preset order parameter of the secp256r1 elliptic curve. This order parameter is a fixed hexadecimal value FFFFFFFF00000000FFFFFFFFFFFFFFFFBCE6FAADA7179E84F3B9CAC2FC632551. It then performs a large integer comparison operation between the candidate random number and this order parameter. If the candidate random number is greater than or equal to the order parameter, it is discarded and regenerated until the candidate random number is strictly less than the order parameter. A 256-bit candidate random number, verified by non-zero checksum and order check, is determined as the four-way vehicle temporary private key. This temporary private key is written into a separate temporary private key register within the hardware security module. This register is configured to be accessible only by the elliptic curve multiplication engine within the hardware security module, and cannot be accessed from the external bus or mapped to the system memory address space. This four-way vehicle temporary private key will not appear in plaintext or ciphertext form on any storage medium or communication interface outside the hardware security module before the end of this session's key negotiation process.

[0069] In this embodiment, the basis for employing the non-zero check is that in elliptic curve cryptography, a private key with all zeros is invalid. If a private key with all zeros is multiplied by a base point of the elliptic curve, an infinity point on the elliptic curve will be obtained, which cannot be used as a temporary public key for subsequent key exchange. The basis for employing the order check is that in elliptic curve scalar dot product operations, the actual effect of the private key is equivalent to the remainder after taking the private key modulo the order of the elliptic curve. If the private key is greater than or equal to the order, the corresponding effective private key is the smaller value after taking the private key modulo the order. This leads to non-uniform use of the private key space, reducing the actual security strength. Therefore, the private key must be restricted to the range from order one to order minus one.

[0070] A1023. The elliptic curve dot product operation engine in the four-way vehicle hardware security module reads the standard generator coordinates of the secp256r1 elliptic curve from the secure storage area. The generator's horizontal coordinate Gx is a fixed hexadecimal value 6B17D1F2E12C4247F8BCE6E563A440F277037D812DEB33A0F4A13945D898C296, and the generator's vertical coordinate Gy is a fixed hexadecimal value 4FE342E2FE1A7F9B8EE7EB4A7C0F9E162BCE33576B315ECECBB6406837BF51F5. The elliptic curve dot product engine uses the four-way vehicle temporary private key as a scalar and this generator as the dot product base point. It employs the Montgomery stepwise algorithm to perform elliptic curve scalar dot product operations. This algorithm performs a uniform sequence of dot addition and doubling operations on each bit of the temporary private key, making the power consumption and execution time independent of the Hamming weight of the temporary private key, thus resisting side-channel attacks. During the operation, the elliptic curve dot product engine uses hardware-accelerated modular multipliers and modular adders to perform addition and multiplication operations within a finite field. The prime number for the modular operation is taken as the prime number p defined by the secp256r1 curve, with a value of FFFFFFFF00000001000000000000000000000000FFFFFFFFFFFFFFFFFFFFFFFF. After the scalar dot product operation is completed, a point on the elliptic curve is obtained. The elliptic curve dot product operation engine performs an infinity check on the coordinates of this point, that is, compares the coordinates of this point with the coordinates of the infinity point. After confirming that the point is not the infinity point, the point is used as a temporary public key point.

[0071] The A1024 elliptic curve dot product engine performs uncompressed dot encoding on the temporary public key points. The encoding process is as follows: the x-coordinate of the temporary public key point is converted into a 32-byte big-endian unsigned integer representation, with the most significant byte at the lowest address; the y-coordinate of the temporary public key point is converted into a 32-byte big-endian unsigned integer representation; a 65-byte string is generated, with the first byte filled with the hexadecimal value 0x04, indicating the uncompressed dot format identifier. Bytes 1 to 32 after the first byte are filled with the 32-byte representation of the x-coordinate, and bytes 33 to 64 are filled with the 32-byte representation of the y-coordinate. This 65-byte string is the four-way vehicle temporary public key. The reason for using uncompressed dot encoding is that it contains the complete values ​​of both the x-coordinate and y-coordinate, allowing the receiver to directly read the dual coordinates without performing a modulo-square root operation to recover the y-coordinate, reducing the computational latency of key negotiation response message processing; in scenarios where there are sufficient computing resources on the warehouse gateway side, the impact of transmitting an additional 32 bytes of y-coordinate data on network load is negligible.

[0072] A1025. The four-way vehicle constructs a key negotiation request message as follows: After rereading the session status register and confirming that the current session status is still in negotiation, the four-way vehicle constructs a message containing a message type identifier field, a four-way vehicle device identifier field, a temporary public key length field, and a temporary public key data field. The message type identifier field is 1 byte, filled with a preset constant value to indicate that this message is a key negotiation request type; the four-way vehicle device identifier field is 8 bytes, filled with the unique device number obtained by the four-way vehicle when registering with the warehouse management system; the temporary public key length field is 2 bytes, filled with the unsigned integer 65, representing the byte length of the temporary public key data field; the temporary public key data field is 65 bytes, filled with the uncompressed dot-coded byte string generated by A1024. The four-way vehicle concatenates the message type identifier field, the four-way vehicle device identifier field, the temporary public key length field, and the temporary public key data field into a complete message, calculates the message length and fills it into the radio link layer frame length field, and sends the key negotiation request message to the warehouse gateway in plaintext form through the established radio link. After the transmission is completed, the four-way vehicle starts the key negotiation response timer and sets the waiting timeout period to a preset value. If the key negotiation response message from the warehouse gateway is not received within the preset timeout period, the negotiation is deemed to have failed due to timeout. The hardware security module will overwrite the temporary private key register with all zeros, erase the temporary private key, and clear the session state register to the initial idle state.

[0073] A103. The warehouse gateway generates a temporary private key and performs a dot product operation on the temporary private key using the elliptic curve base points to obtain a temporary public key. The temporary public key is then sent to the four-way vehicle. Specifically:

[0074] A1031. After receiving a key negotiation request message from the four-way vehicle, the warehouse gateway first parses the message type identifier field. After confirming that the message type is a key negotiation request, it extracts the four-way vehicle device identifier field and the four-way vehicle temporary public key field from the message. Using the four-way vehicle device identifier as an index, the warehouse gateway queries the registered device fingerprint database to determine if the four-way vehicle device identifier exists in the database. If it does not exist, the key negotiation request message is discarded, the subsequent key negotiation process is not executed, and an unregistered device access alarm is sent to the warehouse management system. If it exists, the gateway reads the device fingerprint digest corresponding to the four-way vehicle device identifier from the registered device fingerprint database, temporarily stores the device fingerprint digest in the device fingerprint digest register within the hardware security module, and simultaneously temporarily stores the four-way vehicle temporary public key in the counterparty's temporary public key register within the hardware security module, continuing the gateway temporary private key generation process.

[0075] A1032. The warehouse gateway checks whether a session key negotiation record with a status of "negotiation in progress" corresponding to the four-way vehicle device identifier already exists in the hardware security module. If it exists, the current negotiation request is terminated and a negotiation conflict error response message is returned to the four-way vehicle. If it does not exist, the "negotiation in progress" status identifier is written into the session status register of the hardware security module, and the session identifier is set as the unique identifier for this key negotiation. A new record is created in the session record table to record the correspondence between the four-way vehicle device identifier and the session identifier.

[0076] A1033. The warehouse gateway calls the true random number generator within the hardware security module to generate a temporary private key for the gateway. The true random number generator collects physical noise signals from a hardware entropy source, obtains the original entropy value sequence through analog-to-digital conversion and entropy extraction algorithms, and inputs the original entropy value sequence into a hash-based deterministic random bit generator conforming to the NISTSP800-90A standard to generate a 256-bit candidate random number. The hardware security module sequentially performs non-zero check and order check on the candidate random number: The non-zero check performs a bitwise logical OR operation on all 256 bits of the candidate random number and the all-zero bit string. If every bit of the result is zero, the candidate random number is determined to be all zeros, discarded, and regenerated until it passes the non-zero check. The order check reads the order parameter of the preset secp256r1 elliptic curve, which is a fixed hexadecimal value FFFFFFFF00000000FFFFFFFFFFFFFFFFBCE6FAADA7179E84F3B9CAC2FC632551. The candidate random number is compared with this order parameter as a large integer. If the candidate random number is greater than or equal to the order parameter, it is discarded and regenerated until the candidate random number is strictly less than the order parameter. A 256-bit candidate random number, verified by non-zero checksum and order check, is determined as the gateway's temporary private key. This temporary private key is written into a separate gateway temporary private key register within the hardware security module. This register is configured to be accessible only by the elliptic curve multiplication engine within the hardware security module and not by external bus. This temporary private key will not appear in plaintext or ciphertext form on any storage medium or communication interface outside the hardware security module before the end of this session's key negotiation process.

[0077] The basis for using non-zero checksums and order checks is completely consistent with that of the four-way vehicle side in A1022, namely, a private key with all zeros is an invalid private key, and a private key with an order greater than or equal to that of an elliptic curve will lead to uneven use of the private key space, reducing the actual security strength. The above two checks must be used to ensure the cryptographic validity of the gateway's temporary private key.

[0078] A1034. The elliptic curve dot product operation engine in the warehouse gateway hardware security module reads the standard generator coordinates of the secp256r1 elliptic curve from the secure storage area. The generator's horizontal coordinate Gx is a fixed hexadecimal value 6B17D1F2E12C4247F8BCE6E563A440F277037D812DEB33A0F4A13945D898C296, and the generator's vertical coordinate Gy is a fixed hexadecimal value 4FE342E2FE1A7F9B8EE7EB4A7C0F9E162BCE33576B315ECECBB6406837BF51F5. The elliptic curve dot product engine uses the gateway's temporary private key as a scalar and its generator as the dot product base point. It employs the Montgomery stepwise algorithm to perform elliptic curve scalar dot product operations. This algorithm performs a uniform sequence of dot addition and doubling operations on each bit of the gateway's temporary private key, making the power consumption and execution time independent of the Hamming weight of the gateway's temporary private key, thus resisting side-channel attacks. During the operation, the elliptic curve dot product engine uses hardware-accelerated modular multipliers and modular adders to perform addition and multiplication operations within a finite field. The prime number for the modular operation is taken as the prime number p defined by the secp256r1 curve, with a value of FFFFFFFF00000001000000000000000000000000FFFFFFFFFFFFFFFFFFFFFFFF. After the scalar dot product operation is completed, a point on the elliptic curve is obtained. The elliptic curve dot product operation engine performs an infinity check on the coordinates of this point, that is, compares the coordinates of this point with the coordinates of the infinity point. After confirming that the point is not the infinity point, the point is used as the gateway temporary public key point.

[0079] The reason why the warehouse gateway side uses the same elliptic curve parameters and the same Montgomery step algorithm as the four-way vehicle side is that the key negotiation protocol requires both parties to perform equivalent operations on the same elliptic curve group. Only by using the same curve parameters and algorithm can the shared secret calculated independently by both parties in A104 be numerically consistent. The reason for using the Montgomery step algorithm to uniformly perform point addition and doubling operations is consistent with A1023, which aims to eliminate the dependence of computational power consumption and timing on the private key bit value and prevent attackers from extracting the gateway's temporary private key through power consumption analysis or timing analysis.

[0080] The A1035 elliptic curve dot product engine performs uncompressed point encoding on the gateway's temporary public key point. The encoding process is as follows: the x-coordinate of the gateway's temporary public key point is converted to a 32-byte big-endian unsigned integer representation, with the most significant byte at the lowest address; the y-coordinate of the gateway's temporary public key point is converted to a 32-byte big-endian unsigned integer representation; a 65-byte string is generated, with the first byte padded with the hexadecimal value 0x04, indicating the uncompressed point format identifier. Bytes 1 to 32 following the first byte are filled with the 32-byte representation of the x-coordinate, and bytes 33 to 64 are filled with the 32-byte representation of the y-coordinate. This 65-byte string is the gateway's temporary public key.

[0081] A1036. The warehouse gateway constructs a key negotiation response message. The message includes a message type identifier field, a warehouse gateway device identifier field, a four-way vehicle device identifier field, a session identifier field, a gateway temporary public key length field, a gateway temporary public key data field, and a digital signature field. The message type identifier field is 1 byte, filled with a preset constant value to indicate that this message is a key negotiation response type; the warehouse gateway device identifier field is 8 bytes, filled with the unique device number obtained by the warehouse gateway when registering with the warehouse management system; the four-way vehicle device identifier field is 8 bytes, filled with the four-way vehicle device identifier extracted in A1031, used by the four-way vehicle side to verify the correspondence between the response message and the request message; the session identifier field is 8 bytes, filled with the session identifier generated in A1032; the gateway temporary public key length field is 2 bytes, filled with an unsigned integer 65, representing the byte length of the gateway temporary public key data field; the gateway temporary public key data field is 65 bytes, filled with the uncompressed dot-coded byte string generated in A1035. The warehouse gateway uses the pre-installed ECDSA digital signature private key within its hardware security module to perform ECDSA digital signature operations on the concatenated data of the message type identifier field, warehouse gateway device identifier field, four-way vehicle device identifier field, session identifier field, gateway temporary public key length field, and gateway temporary public key data field. The signature algorithm uses secp256r1 elliptic curve cryptography, and the signature result is a DER-encoded signature value byte string, which is then filled into the digital signature field. The warehouse gateway concatenates all the above fields sequentially into a complete message, calculates the message length and fills it into the radio link layer frame length field, and sends the key negotiation response message to the four-way vehicle via the radio link. After transmission, the warehouse gateway starts a key negotiation completion waiting timer, setting the waiting timeout period to a preset value. If no key negotiation confirmation message is received from the four-way vehicle within the preset timeout period, the negotiation is deemed to have timed out and failed. The hardware security module overwrites the gateway temporary private key register with all zeros, erases the gateway temporary private key, clears the session state register to the initial idle state, and releases the session negotiation record.

[0082] A104. The four-way vehicle performs a dot product operation between its temporary private key and the temporary public key of the gateway to obtain a first shared secret, and the warehouse gateway performs a dot product operation between its temporary private key and the temporary public key of the four-way vehicle to obtain a second shared secret.

[0083] In this embodiment, the process of calculating the first shared secret on the four-way vehicle side is as follows: the four-way vehicle receives the key negotiation response message sent by the warehouse gateway, parses the message and extracts the gateway temporary public key field, and reads the horizontal and vertical coordinates of the gateway temporary public key point from the 65-byte uncompressed dot-coded byte string of the gateway temporary public key field. The four-way vehicle verifies the ECDSA digital signature carried in the key negotiation response message. The signature verification uses the secp256r1 elliptic curve and a pre-set warehouse gateway signature verification public key. If the signature verification fails, the response message is discarded, the four-way vehicle's temporary private key is erased, the session state register is cleared to the initial idle state, and the key negotiation process is terminated. If the signature verification passes, the elliptic curve dot product operation engine in the four-way vehicle's hardware security module reads the four-way vehicle's temporary private key from the temporary private key register, uses the gateway's temporary public key point as the dot product base point, and performs the elliptic curve scalar dot product operation using the Montgomery step algorithm. After the operation is completed, the result point is checked for infinity. After confirming that the result point is not an infinity point, the 256-bit big-endian unsigned integer representation of the x-coordinate of the point is extracted as the four-way vehicle's shared secret, and this shared secret is written into the shared secret register in the hardware security module.

[0084] In this embodiment, the process of calculating the second shared secret on the warehouse gateway side is as follows: After receiving the key negotiation confirmation message sent by the four-way vehicle, the warehouse gateway reads the gateway's temporary private key from the gateway's temporary private key register and reads the coordinates of the four-way vehicle's temporary public key point temporarily stored in A1031 from the other party's temporary public key register. Using the four-way vehicle's temporary public key point as the base point for the dot product, the same Montgomery step algorithm and secp256r1 curve parameters as on the four-way vehicle side are used to perform the elliptic curve scalar dot product operation. After the operation is completed, the result point is checked for infinity. After confirming that the result point is not an infinity point, the 256-bit big-endian unsigned integer representation of the abscissa of the point is extracted as the shared secret on the warehouse gateway side, and the shared secret is written into the shared secret register in the hardware security module.

[0085] In this embodiment, the consistency between the shared secret on the four-way vehicle side and the shared secret on the warehouse gateway side is based on the following: The four-way vehicle side calculates the dot product of the four-way vehicle's temporary private key and the gateway's temporary public key. The gateway's temporary public key is obtained by multiplying the gateway's temporary private key and the elliptic curve's base point. Therefore, the shared secret on the four-way vehicle side equals the four-way vehicle's temporary private key multiplied by the gateway's temporary private key multiplied by the elliptic curve's base point. Similarly, the warehouse gateway side calculates the dot product of the gateway's temporary private key and the four-way vehicle's temporary public key. The four-way vehicle's temporary public key is obtained by multiplying the four-way vehicle's temporary private key and the elliptic curve's base point. Therefore, the shared secret on the warehouse gateway side equals the gateway's temporary private key multiplied by the four-way vehicle's temporary private key multiplied by the elliptic curve's base point. According to the commutative law of elliptic curve scalar multiplication, both point to the same point on the elliptic curve, and the values ​​obtained by extracting the x-coordinate of this point are exactly the same. Thus, both parties independently obtain the same shared secret without exchanging any private key information.

[0086] A105. Concatenate the first shared secret and the second shared secret with the device fingerprint digest respectively to obtain the first concatenated secret and the second concatenated secret;

[0087] In this embodiment, the specific process of the four-way vehicle side performing the splicing operation is as follows: the four-way vehicle hardware security module reads the shared secret from the shared secret register, reads the 256-bit device fingerprint digest stored in A101 from the device fingerprint digest register, places all 256 bits of the shared secret in the high bit and all 256 bits of the device fingerprint digest in the low bit, splices them bit by bit into a 512-bit splicing result, and writes the splicing result into the key derivation input buffer in the hardware security module.

[0088] In this embodiment, the specific process of the splicing operation performed on the warehouse gateway side is as follows: The warehouse gateway hardware security module reads the shared secret from the shared secret register, reads the 256-bit device fingerprint digest temporarily stored in A1031 from the device fingerprint digest register, and, in the same order as on the four-way vehicle side, places the shared secret in the high bit and the device fingerprint digest in the low bit, splicing them bit by bit into a 512-bit splicing result, which is then written to the key derivation input buffer. The basis for both parties using the same splicing order is that the splicing order constitutes the input format convention of the key derivation function. Both parties must use a completely consistent splicing order to ensure that the subsequently generated session keys are numerically identical. If the splicing order of either party is inconsistent with that of the other party, the derived session keys will be different, and subsequent encrypted communication will not be able to be decrypted normally.

[0089] In this embodiment, the basis for introducing the device fingerprint digest into the concatenation operation is that the shared secret in the standard Diffie-Hellman protocol relies only on the temporary public-private key pair between the communicating parties, and is independent of the specific device identity involved in the communication. If an attacker impersonates the network identifier of a four-way vehicle and completes a Diffie-Hellman exchange with the warehouse gateway, without the introduction of device fingerprint binding, the attacker will obtain the same shared secret as the legitimate four-way vehicle, thereby enabling the decryption of subsequent business data communication. This embodiment, by concatenating the device fingerprint digest and the shared secret before inputting them into the key derivation function, ensures that the final generated session key simultaneously relies on the difficulty of the elliptic curve discrete logarithm problem and the uniqueness of the device fingerprint. The device fingerprint of the impersonating device differs from that of the legitimate device, and its device fingerprint digest is also different. Even if the impersonating device obtains the same shared secret through a Diffie-Hellman exchange, the concatenation result is still inconsistent with the concatenation result on the warehouse gateway side. The final generated session key is different, and the impersonating device cannot decrypt the ciphertext of the scheduling instructions issued by the warehouse gateway, nor can the warehouse gateway decrypt the forged data uploaded by the impersonating device, thus achieving a cryptographic binding between the session key and the device identity.

[0090] A106. Input the first concatenated secret and the second concatenated secret into the hash-based message authentication code key derivation function to generate the session key, so that the session key is simultaneously bound to the shared secret and the device fingerprint of the four-way vehicle.

[0091] In this embodiment, the four-way vehicle and the warehouse gateway each use the 512-bit concatenation result obtained from A105 as input key material, and generate a session key using the HKDF key derivation function based on HMAC-SHA256. Specifically, the concatenation result is used as the input key material parameter of the HKDF key derivation function, and a preset 128-bit fixed string is used as the salt value parameter. This salt value is pre-shared by the four-way vehicle and the warehouse gateway through a secure channel during the system deployment initialization phase and stored in their respective hardware security modules. The current job task record in the session log table in A1021 is used as the salt value parameter. The task identifier, used as an info context information parameter, is uniformly assigned by the warehouse management system when the scheduling instruction is issued, and a correspondence is established between the task identifier and the session record table. During the extraction phase of the HKDF key derivation function, the input key material and salt value are input into the HMAC-SHA256 operation to calculate a 256-bit pseudo-random key. Then, during the extension phase of the HKDF key derivation function, the pseudo-random key and info context information are used as input, and the HMAC-SHA256 operation generates a 256-bit output key material, which is the session key. Both the four-way vehicle and the warehouse gateway write the session key into the session key register within the hardware security module. This register is configured to be readable only by the AES-GCM-256 encryption engine and the HMAC-SHA256 integrity verification engine of the encryption framing module, and cannot be accessed by the external bus.

[0092] In this embodiment, the HKDF key derivation function is used instead of the concatenated result as the session key because the concatenated result is directly formed by concatenating the shared secret and the device fingerprint digest. Its bit distribution characteristics are limited by the distribution characteristics of the x-coordinate of the elliptic curve points and the distribution characteristics of the SHA-256 hash output, and it is not generated through a cryptographic pseudo-random process, which may result in structural statistical bias. The extraction stage of HKDF compresses and smooths the input key material into a uniformly distributed pseudo-random key through HMAC-SHA256 operation, eliminating possible structural biases in the input material. The expansion stage expands the pseudo-random key into an output key of the required length, and each bit of the output key follows a uniform distribution, satisfying the cryptographic quality requirements of the AES-256 algorithm for session keys.

[0093] In this embodiment, the reason for using the job task identifier as the info parameter input is that the info parameter derives and binds the key to a specific application context. Even if the device fingerprints are the same and the temporary public-private key pairs are exactly the same after regeneration, the session keys output by HKDF will be different in different job tasks for the same four-way vehicle within the same warehouse gateway, thus achieving a mandatory binding of the session key to a single job task. The session keys between different job tasks are cryptographically independent; the leakage of the session key for one job task will not affect the data security of other job tasks, meeting the security management requirement of data isolation at the task granularity in warehouse operations.

[0094] It should be further explained that in this embodiment, the key negotiation module associates the session key with the current job task identifier and destroys the session key in response to a change in the job task identifier or a job completion signal, specifically including the following:

[0095] C101. Configure the session key usage counter and session key status register.

[0096] In this embodiment, the key negotiation module allocates a session key usage counter and a session key status register for each generated session key within the hardware security module. The session key usage counter has a 16-bit width and an initial value of zero, indicating that the current session key has not been used by any encryption operation. The session key status register is 1 bit and takes either a first status value or a second status value. The first status value indicates that the current session key is in an available state, and the second status value indicates that the current session key is in a pending destruction state. Both the session key usage counter and the session key status register are stored in a protected storage area within the hardware security module, and can only be read and written atomically by the key negotiation module and the encryption framing module via the internal hardware bus. When the key negotiation module writes the session key to the session key register in A106, it initializes the corresponding session key usage counter to zero and sets the session key status register to the first status value.

[0097] The rationale for using an internal hardware bus and atomic operations to read and write the session key usage counter is as follows: The encryption framing module needs to increment the session key usage counter during encryption and decrement it upon completion of encryption. These operations may originate from multiple parallel processing branches. If accessed via an external bus using software, a read-modify-write race condition risk exists. Specifically, two parallel branches might simultaneously read the counter's current value, increment it, and write it back, resulting in the counter actually incrementing by one instead of two, causing an error in the count during the encryption operation. Internal hardware atomic operations ensure that the read-modify-write sequence is not interrupted by other operations during execution, guaranteeing the correctness of the counter value.

[0098] C102. The encryption framing module increments the session key by one using a counter when the encryption operation begins.

[0099] In this embodiment, before executing B101 to send the main business data into the first parallel branch, the encryption framing module first reads the value of the session key status register corresponding to the current session key through the internal hardware bus. If the session key status register is a second status value, it indicates that the session key has been marked as to be destroyed. The encryption framing module terminates the current encryption operation, returns a session key unavailable error code to the upper-layer application, and triggers a new round of session key negotiation. If the session key status register is a first status value, the encryption framing module increments the current value of the session key usage counter by one using an atomic addition operation through the internal hardware bus. After incrementing, it then executes the encryption and framing operations from B102 to B105.

[0100] In this embodiment, the encryption framing module checks the session key status register before starting the encryption operation because: when the job task identifier change signal arrives, the session key may have been marked as pending destruction. If the session key is used to encrypt a new service data frame at this time, the generated ciphertext data frame will be undecryptable at the receiving end because the session key has been destroyed, resulting in loss of service data and waste of transmission resources. By setting a status checkpoint at the entry point of the encryption operation, it can be ensured that the session key in the pending destruction state will not be used by new encryption operations, and only data frames already in the encryption process are allowed to continue to complete the encryption.

[0101] C103. After completing the encryption operation, the encryption framing module decrements the session key by one using a counter.

[0102] In this embodiment, after the encrypted data frame is successfully transmitted to the receiving end via the wireless link by B105, the encryption framing module decrements the current value of the session key usage counter by one through an atomic subtraction operation on the internal hardware bus. After the decrement operation is completed, the hardware security module automatically compares the current value of the session key usage counter with the zero value. If the current value is equal to zero and the session key status register is in the second status value, the hardware security module generates a session key destruction trigger signal and enters the destruction process of C105. The basis for this automatic hardware comparison and triggering mechanism is that there is a time sequence uncertainty between the time when the session key usage counter reaches zero and the time when the job task identifier change signal arrives. If a software polling method is used to check the counter reaching zero, there is a time window delay caused by the polling interval; the automatic hardware comparison can generate a trigger signal within the same clock cycle when the counter reaches zero, eliminating the response delay introduced by software polling.

[0103] C104. The key negotiation module receives the job task identifier change signal or job completion signal and performs a session key status judgment.

[0104] In this embodiment, the warehouse management system uniformly allocates task identifiers when issuing scheduling instructions, and sends a task completion signal to the key negotiation module after all current tasks are completed, or sends a task identifier change signal carrying the new task identifier when a task is changed. Upon receiving this signal, the key negotiation module first reads the current value of the session key usage counter corresponding to the current session key. If the current value is zero, it determines that no frame of business data is currently being encrypted with the current session key, and immediately issues a session key destruction command to the hardware security module, overwriting the session key register corresponding to the current session key with all zeros, releasing the association record between the current session key and the current task identifier in the session record table, and setting the session key status register to its initial state. If the current value is not zero, it determines that at least one frame of business data is still being encrypted with the current session key, and the key negotiation module temporarily stores the received task identifier change signal or task completion signal in the pending signal queue within the hardware security module, while simultaneously rewriting the session key status register from the first state value to the second state value to prevent subsequent new encryption operations from using the session key. The key negotiation module enables the session key usage counter of the hardware security module to be reset to zero interrupt. When the hardware security module detects that the session key usage counter has been reset to zero and the session key status register is in the second status value, it generates an interrupt signal to notify the key negotiation module to execute the destruction process of C105.

[0105] The basis for switching the session key status register between the first and second status values ​​is that, within the time window after the job task identifier change signal arrives but before the session key usage counter reaches zero, the system can distinguish between two states: "a session key that can be used normally" and "a session key waiting to be destroyed but still having in-transit encryption operations." For a session key in the second status value, new encryption operations are intercepted at the entry checkpoint C102, while in-transit operations that have already entered the encryption process can still use the session key to complete encryption and perform a decrement operation in C103. This achieves fine-grained state management between ensuring that in-transit encryption operations are not affected and that new encryption operations are intercepted.

[0106] C105. The session key is destroyed after the session key usage counter is reset to zero.

[0107] In this embodiment, when the hardware security module detects that the current value of the session key usage counter is equal to zero and the session key status register is in the second state value, the hardware security module generates a session key destruction trigger signal. The key negotiation module responds to this trigger signal, retrieves the temporarily stored job task identifier change signal or job completion signal from the pending signal queue, and sends a session key destruction command to the hardware security module. The hardware security module performs the session key destruction operation: it writes all zeros sequentially to the session key register corresponding to the current session key, from low to high bit address, completing the all-zero overwrite; it resets the corresponding session key usage counter to zero; it resets the corresponding session key status register to its initial state; and it deletes the association record between the current session key and the current job task identifier from the session record table. After the session key destruction operation is completed, the key negotiation module uses the changed new job task identifier as input to trigger a new round of session key negotiation, executing steps A1021 to A106.

[0108] As a specific example, in this embodiment, during the four-way vehicle's execution of the cargo handling task identified as TASK001, the current value of the session key usage counter is three, indicating that three business data frames are at different stages of the encryption processing pipeline. At this time, the warehouse management system issues a task identification change signal, with the new task identification being TASK002. The key negotiation module reads that the current value of the session key usage counter is three, which is not equal to zero, determining that there is an in-transit encryption operation. It temporarily stores the task identification change signal in the pending signal queue and rewrites the session key status register from the first status value to the second status value. During the second status value period, when the encryption framing module attempts to perform an encryption operation on the fourth frame of business data, it reads the session key status register as the second status value at the C102 entry check, terminates the current encryption, and returns an error code to the caller. After the three in-transit business data frames are successively encrypted and sent, the session key usage counter decreases sequentially to two, one, and zero. When the session key usage counter reaches zero and the session key status register is in the second state value, the hardware security module generates a destruction trigger signal, the key negotiation module destroys the session key corresponding to TASK001, and starts a new round of session key negotiation process with TASK002 as input.

[0109] In this embodiment, the business data body is encrypted using the AES-GCM-256 algorithm, and the session key is encrypted using the RSA-2048 algorithm. A specific implementation of calculating the SHA-256 hash value of the encrypted business data body is as follows:

[0110] B101. The business data body to be transmitted and the currently valid session key are input into the parallel processing pipeline. Specifically, the encryption framing module reads the session key bound to the current job task from the session key register of the hardware security module, and reads the business data body to be transmitted from the data transmission buffer of the four-way vehicle control unit. The encryption framing module encapsulates the business data body and the session key into a first processing task and a second processing task, respectively. The first processing task is submitted to the AES acceleration engine in the hardware security module, and the second processing task is submitted to the RSA acceleration engine in the hardware security module. The two engines obtain input data through independent direct memory access channels and achieve synchronous start-up through hardware semaphores. There is no data dependency between the two engines, and they do not wait for each other's output results.

[0111] B102. In the first parallel branch, the business data subject is encrypted using the AES-GCM-256 algorithm. Specifically, the encryption framing module calls the AES-GCM-256 encryption engine in the hardware security module, uses the session key as the encryption key, and calls the true random number generator to generate a 96-bit initialization vector. The AES-GCM-256 encryption engine takes the session key, initialization vector, and business data body as input and performs the following operations: First, using the session key as input, it performs an AES-256 key expansion operation, expanding the 256-bit session key into 15 round keys of 128 bits each; second, it inputs the initialization vector and session key into the GCM initialization function to generate a 128-bit initial counter value; then, it divides the business data body into multiple plaintext blocks of 128 bits each, and performs 14 rounds of encryption transformations (AddRoundKey, SubBytes, ShiftRows, MixColumns, AddRoundKey) on each plaintext block sequentially, omitting the MixColumns operation in the last round. Each plaintext block outputs a 128-bit ciphertext block after encryption transformation, and all ciphertext blocks are concatenated in order to obtain the business data ciphertext; simultaneously, the AES-GCM-256 encryption engine inputs all bits of the business data ciphertext, the initialization vector, and additional authentication data into the GHASH operation unit, based on the finite field GF(2 128 The multiplication and addition operations on the hash table are performed, using the hash subkey derived from the session key as the initial value, to calculate a 128-bit authentication tag. This authentication tag is the first authentication tag. The first authentication tag is used by the receiving end to verify whether the encrypted business data has been tampered with during transmission.

[0112] B103. Synchronously, in the second parallel branch, the session key is encrypted using the RSA-2048 algorithm and the public key of the warehouse gateway. Specifically, the encryption framing module reads the RSA-2048 public key of the warehouse gateway from the secure storage area of ​​the hardware security module. This public key is generated by the warehouse gateway during the system deployment initialization phase and distributed to the four-way vehicle through a secure channel. The encryption framing module uses the warehouse gateway's RSA-2048 public key as the encryption key and performs encryption on the session key according to the RSAES-OAEP padding scheme specified in the RSA-PKCS#1v2.2 standard: First, using the session key as plaintext input for OAEP padding, a true random number generator is called to generate a 256-bit random seed; second, the random seed is input into the MGF1 mask generation function, using SHA-256 as the hash function, to generate a mask value of the same length as the plaintext. The mask value is then compared with the plaintext... The plaintext after being masked is obtained by bitwise XOR; then, the plaintext after being masked is input into the MGF1 mask generation function to generate a mask value of the same length as the random seed. The mask value is then XORed with the random seed to obtain the seed after being masked; the seed after being masked is concatenated with the plaintext after being masked to obtain the encoded message after OAEP padding; finally, a large integer modular exponentiation operation is performed on the encoded message after padding using the modulus and public exponent of the warehouse gateway RSA-2048 public key, and the square-multiplication algorithm is used to iteratively calculate bitwise to generate a 256-byte session key ciphertext. Since the RSA encryption operation and the AES encryption operation are executed synchronously in the second parallel branch and the first parallel branch, the time consumption of the RSA modular exponentiation operation is overlapped by the execution time of the AES encryption operation and the subsequent hash operation. The total delay of the encryption framing process is determined by the branch with the longest time consumption, rather than the sum of the time consumption of each branch in the non-serial mode, thus eliminating the problem of RSA encryption becoming the bottleneck of framing.

[0113] In this embodiment, the basis for adopting the RSAES-OAEP padding scheme is that: OAEP padding is a provably secure padding scheme that can resist chosen ciphertext attacks and has stronger security than PKCS#1v1.5 padding; random numbers are introduced during the OAEP padding process, so that the ciphertext of the session key generated by the same session key in different encryption operations is different, preventing attackers from determining whether the session key is reused by comparing ciphertexts.

[0114] B104. Calculate the SHA-256 hash value independently for the ciphertext of the business data and the ciphertext of the session key. Specifically: After the encryption framing module completes AES-GCM-256 encryption in the first parallel branch, it uses all bytes of the ciphertext of the business data output by B102 as the sole input for the SHA-256 hash operation, excluding the initialization vector and the first authentication tag. After iterative computation by the SHA-256 compression function, it outputs a 256-bit first hash value. After completing RSA-2048 encryption in the second parallel branch, it uses all 256 bytes of the ciphertext of the session key output by B103 as the sole input for the SHA-256 hash operation, excluding the RSA public key and padding parameters. After iterative computation by the SHA-256 compression function, it outputs a 256-bit second hash value. The first hash value is used by the receiving end to determine the integrity of the business data ciphertext simply by calculating the hash value of the ciphertext and comparing it with the first hash value, without decrypting the session key ciphertext or performing RSA decryption. The second hash value is used by the receiving end to determine the integrity of the session key ciphertext simply by calculating the hash value of the ciphertext and comparing it with the second hash value after obtaining the session key ciphertext and before performing RSA decryption.

[0115] In this embodiment, the reason for calculating the hash values ​​of the encrypted business data and the encrypted session key separately is that if the two are combined and a single hash value is calculated, the receiving end, after receiving the encrypted data frame, must wait for RSA decryption to obtain the session key, then use the session key to decrypt the encrypted business data and verify the authentication tag before it can determine the integrity and authenticity of the data. This makes it impossible to identify tampered encrypted business data in the early stages of reception. By calculating the first and second hash values ​​separately, the receiving end can immediately extract the encrypted business data, calculate the hash value, and compare it with the first hash value after receiving the encrypted data frame. This operation only involves SHA-256 operations, which take much less time than RSA decryption. If the comparison fails, the frame is discarded directly without performing subsequent RSA decryption operations, thus avoiding invalid or tampered data frames occupying the receiving end's RSA decryption resources and shortening the detection delay of abnormal data.

[0116] B105. Assemble the encrypted business data, first authentication tag, first hash value, encrypted session key, second hash value, and initialization vector into an encrypted data frame. Specifically, the frame structure of the encrypted data frame includes, in sequence: a frame header identifier field (2 bytes), filled with a preset constant value to identify this message as an encrypted data frame; a frame sequence number field (4 bytes), filled with the incrementing frame sequence number of this transmission, used for fragment positioning during breakpoint resumption; an initialization vector field (12 bytes), filled with a 96-bit random initialization vector generated by B102; and a business data encrypted length field (2 bytes), filled with the length of the encrypted business data. The frame structure includes the following fields: Length value; Business data ciphertext field, variable length, filled with the business data ciphertext output by B102; First authentication tag field, 16 bytes, filled with the 128-bit first authentication tag output by B102; First hash value field, 32 bytes, filled with the 256-bit first hash value output by B104; Session key ciphertext length field, 2 bytes, filled with a fixed value of 256, indicating the byte length of the session key ciphertext; Session key ciphertext field, 256 bytes, filled with the session key ciphertext output by B103; Second hash value field, 32 bytes, filled with the 256-bit second hash value output by B104. The reason for placing the first hash value field before the session key ciphertext field in the above frame structure is that when the receiving end parses the frame in the order of the frame structure, it can first read the business data ciphertext and the first hash value to complete the first-layer integrity verification without having to cross the session key ciphertext area for addressing, reducing the overhead of parsing state switching. The encryption framing module concatenates the above fields in order and sends the ciphertext data frame to the receiving end through the wireless link.

[0117] B106. After receiving the encrypted data frame, the receiving end performs layered integrity verification and decryption. Specifically, the receiving end first parses the encrypted data frame, extracts the frame header identifier field to confirm the message type, extracts the frame sequence number field to record the reception status, and extracts the service data encrypted field and the first hash value field. Using all bytes of the service data encrypted field as input, it independently performs a SHA-256 hash operation to obtain the first check hash value. The first check hash value is compared bit-by-bit with the value in the first hash value field. If the comparison is inconsistent, it is determined that the service data encrypted text has been tampered with during transmission, and the encrypted data frame is directly discarded without performing RSA decryption. If the first hash value comparison is consistent, the receiving end extracts the session key encrypted field and the second hash value field. Using all 256 bytes of the session key encrypted field as input, it independently performs a SHA-256 hash operation to obtain the second check hash value. The second check hash value is compared bit-by-bit with the value in the second hash value field. If the comparison is inconsistent, it is determined that the session key encrypted text has been tampered with during transmission, and the encrypted data frame is directly discarded. If the second hash value matches, the receiving end performs RSAES-OAEP decryption on the ciphertext of the session key using the RSA-2048 private key of the warehouse gateway. This involves first performing a large integer modular exponentiation operation on the ciphertext of the session key using the private key modulus and private exponent to obtain the RSAES-OAEP encoded message. Then, following the RSAES-OAEP decoding process specified in the PKCS#1v2.2 standard, the session key plaintext is extracted from the encoded message. This decoding process specifically includes: using the encoded message as input, recovering the random seed through the mask generation function MGF1; using the random seed to perform an XOR operation on the masked data to restore it; then performing padding verification on the restored data; stripping the padding field and hash label; and finally outputting the session key plaintext.

[0118] The receiving end uses the session key plaintext and initialization vector as parameters to perform AES-GCM-256 decryption on the ciphertext of the business data. During the decryption process, the session key plaintext, initialization vector, and ciphertext of the business data are used as inputs to perform AES-GCM-256 authentication and decryption operations. The decrypted business data body is output, and a GHASH operation is performed simultaneously to obtain the second authentication tag. The value in the field of the second authentication tag is compared bit by bit with that in the first authentication tag. If the authentication tags match, the decrypted business data body is submitted to the upper-layer application. If the authentication tags do not match, it is determined that the business data has been tampered with during encryption or transmission, the frame data is discarded, and an integrity verification failure event is reported to the warehouse management system.

[0119] As a specific example, in this embodiment, the four-way vehicle sends a 128-byte scheduling instruction feedback data to the warehouse gateway as the main body of the business data. In the first parallel branch, the AES-GCM-256 encryption engine encrypts the 128-byte business data body with a 256-bit session key and a 96-bit random initialization vector, outputting 128 bytes of ciphertext business data and a 16-byte first authentication tag. The SHA-256 hash operation outputs a 32-byte first hash value. Simultaneously, in the second parallel branch, the RSA-2048 encryption engine performs OAEP padding and modular exponentiation on the 256-bit session key with the warehouse gateway's 2048-bit RSA public key, outputting 256 bytes of session key ciphertext. The SHA-256 hash operation outputs a 32-byte second hash value. The above fields are assembled in sequence into a ciphertext data frame with a total length of 2+4+12+2+128+16+32+2+256+32, totaling 486 bytes. After receiving the 486-byte encrypted data frame, the warehouse gateway first calculates the hash value of the 128-byte encrypted business data and compares it with the first hash value, which takes approximately microseconds. If the comparison passes, it then calculates the hash value of the 256-byte encrypted session key and compares it with the second hash value, also taking approximately microseconds. After both hash comparisons pass, it performs RSA-2048 private key decryption, which takes approximately milliseconds. After obtaining the session key, it completes AES-GCM-256 decryption and authentication tag verification, ultimately obtaining the 128-byte business data body. If an attacker tampers with any bit of the encrypted business data during transmission, the receiving end can detect the tampering and discard the frame during the microsecond-level first hash value comparison stage, avoiding the subsequent millisecond-level invalid RSA decryption calculations.

[0120] It should be further explained that in this embodiment, the device fingerprint is extracted to verify the legality of the hardware, the ECDSA digital signature is verified to confirm the authenticity of the data source, and the warehouse area identifier is extracted to confirm the compliance of the access scenario. Specifically, this includes:

[0121] D101. The receiving end extracts the sender's storage area identifier field, the sender's device fingerprint field, and the sender's ECDSA digital signature field from the frame header extension field of the encrypted data frame.

[0122] In this embodiment, the frame header extension field of the ciphertext data frame is located after the frame header identifier field and before the initialization vector field of the ciphertext data frame. The frame structure of the frame header extension fields includes, in sequence: Sender Warehouse Area Identifier Length field (1 byte, filled with the byte length value of the sender's warehouse area identifier); Sender Warehouse Area Identifier field (variable length, filled with the warehouse area identifier string bound to the sender's four-way vehicle during registration, which is uniformly assigned by the warehouse management system during the device registration phase based on the warehouse area number deployed by the four-way vehicle); Sender Device Fingerprint Length field (1 byte, filled with the byte length value of the sender's device fingerprint); Sender Device Fingerprint field (variable length, filled with the original string of the sender's four-way vehicle's device fingerprint, which is consistent with the original string of the device fingerprint collected in A1011); Sender ECDSA Digital Signature Length field (2 bytes, filled with the byte length value of the sender's ECDSA digital signature); Sender ECDSA Digital Signature field (variable length, filled with the DER encoding and ECDSA digital signature value generated by the sender's four-way vehicle calculating the signature of all fields in the ciphertext data frame except this field when assembling the ciphertext data frame in B105). The receiving end parses the frame header extension fields sequentially according to the above frame structure, extracts all bytes of the sender's storage area identifier field, all bytes of the sender's device fingerprint field, and all bytes of the sender's ECDSA digital signature field, and stores them in the corresponding areas of the authentication input buffer in the hardware security module.

[0123] D102. Perform the first layer of verification, namely the access scenario compliance verification, by comparing the sender's storage area identifier with the current access storage area identifier pre-set in the receiver's hardware security module byte by byte.

[0124] In this embodiment, during the system deployment initialization phase, the warehouse management system writes the current access warehouse area identifier string to the secure storage area of ​​the receiver's hardware security module. This string represents the unique number of the warehouse area where the receiver is located, for example, the warehouse area number string A3. The receiver reads all bytes of the sender's warehouse area identifier field extracted by D101 from the authentication input buffer, and reads all bytes of the preset current access warehouse area identifier string from the secure storage area to obtain the byte length L1 of the sender's warehouse area identifier and the byte length L2 of the current access warehouse area identifier. The receiver first compares whether L1 and L2 are equal. If they are not equal, the access scenario compliance verification is determined to have failed, the encrypted data frame is directly discarded, the authentication process is terminated, and no further verification is performed. If L1 equals L2, the receiving end starts from the first byte of the sender's storage area identifier and sequentially performs a bitwise XOR operation with the corresponding byte of the current access storage area identifier. If the XOR result of all L1 pairs of bytes is zero, it is determined that the sender's storage area identifier is consistent with the current access storage area identifier, the access scenario compliance verification is passed, and the process proceeds to D103. If the XOR result of any pair of bytes is non-zero, it is determined that the two are inconsistent, the access scenario compliance verification fails, the encrypted data frame is discarded, and the authentication process is terminated.

[0125] The rationale for using access scenario compliance verification as the first layer of verification is that byte-by-byte comparison of the warehouse area identifier only involves string equality judgment, with a computational overhead of one linear traversal of the byte length, without involving any cryptographic operations, making it the least computationally expensive among the three layers of verification. If the sender initiates unauthorized cross-regional access from a region other than the current warehouse area, the sender's warehouse area identifier filled in the encrypted data frame will inevitably be inconsistent with the receiver's current access warehouse area identifier. This can be detected and discarded in the first step, avoiding the consumption of higher-overhead operations such as subsequent device fingerprint matching and ECDSA digital signature verification by invalid frames. The warehouse area identifier string is uniformly allocated by the warehouse management system during the device registration phase and written into the hardware security module of each device. Attackers cannot obtain the warehouse area identifier of other regions by eavesdropping on the wireless link because the warehouse area identifier does not appear in any plaintext messages during key negotiation and encrypted transmission.

[0126] D103. If the access scenario compliance verification passes, the second layer of verification, namely hardware legality verification, is executed, which compares the sender's device fingerprint with each registered device fingerprint stored in the registered device fingerprint database byte by byte.

[0127] In this embodiment, the registered device fingerprint database of the receiving end is stored in a protected storage area within the hardware security module. Each record in the registered device fingerprint database includes a device identifier field and a device fingerprint digest field. The device fingerprint digest field stores the 256-bit device fingerprint digest of the device obtained and stored by the warehouse gateway side during the device registration phase in A1014. The receiving end reads all bytes of the sender's device fingerprint field extracted by D101 from the authentication input buffer, performs the same SHA-256 hash operation on the sender's device fingerprint as in A1011 to A1013, and obtains a 256-bit receiving-side device fingerprint digest. The receiving end then compares the receiving-side device fingerprint digest byte-by-byte with the device fingerprint digest field of each record stored in the registered device fingerprint database. The specific process of byte-by-byte comparison is as follows: The receiving end sets the matching flag bit, initially set to false; starting from the first record in the registered device fingerprint database, the 32 bytes of the receiving side's device fingerprint digest and the 32 bytes of the current record's device fingerprint digest field are XORed sequentially in ascending order of byte number. If all XOR results of the 32 pairs of bytes are zero, the matching flag bit is set to true, the device identifier of the current record is recorded, and the traversal is terminated; if the XOR result of any pair of bytes is non-zero, the traversal continues to the next record. When all records have been traversed, if the matching flag bit is still false, it is determined that the sender's device fingerprint does not match any of the registered device fingerprints, the hardware legitimacy verification fails, the encrypted data frame is discarded, the authentication process is terminated, and an alarm event for unregistered device access is reported to the warehouse management system. The alarm event record includes the SHA-256 hash value and timestamp of the sender's device fingerprint. If the matching flag bit is true, the hardware legitimacy verification is determined to be successful, the device identifier corresponding to the matched registered device fingerprint is recorded, and the process proceeds to D104.

[0128] The rationale for placing hardware legitimacy verification as the second layer of verification, preceding ECDSA digital signature verification, is that the computational overhead of hashing and byte-by-byte matching for device fingerprints is significantly lower than the elliptic curve multiplication and modular inverse operations in ECDSA digital signature verification. If the sender's device fingerprint is not registered in the registered device fingerprint database, it can be detected and discarded during the second layer of verification, avoiding the high-overhead ECDSA digital signature verification operations on ciphertext data frames sent from unregistered devices. Furthermore, the extracted sender's device fingerprint is first hashed using a SHA-256 hash value and then matched against the device fingerprint digest in the registered device fingerprint database, rather than directly matching the original device fingerprint string. This is because the registered device fingerprint database stores device fingerprint digests, not the original string, to protect the confidentiality of the device fingerprint; and because the device fingerprint digest is a fixed 256 bits, the matching operation has a fixed length, avoiding the impact of the variable length of the original device fingerprint string on the matching operation time.

[0129] D104. If the hardware legitimacy verification passes, then perform the third layer of verification, namely the data source authenticity verification, and perform signature verification operation on the sender's ECDSA digital signature.

[0130] In this embodiment, the receiving end reads the registered ECDSA verification public key associated with the device identifier corresponding to the registered device fingerprint matched by D103 from the registered device fingerprint database. This registered ECDSA verification public key is generated by the four-way vehicle during the device registration phase and submitted to the warehouse gateway along with the device fingerprint digest. The warehouse gateway stores it in the record corresponding to the device identifier in the registered device fingerprint database. The receiving end uses all remaining fields in the encrypted data frame, excluding the sender's ECDSA digital signature field, as the message to be verified. Specifically, the concatenation range includes: all bytes of the frame header identifier field, all bytes of the frame header extension field excluding the sender's ECDSA digital signature field, all bytes of the frame sequence number field, all bytes of the initialization vector field, all bytes of the business data encrypted length field, all bytes of the business data encrypted field, all bytes of the first authentication tag field, all bytes of the first hash value field, all bytes of the session key encrypted length field, all bytes of the session key encrypted field, and all bytes of the second hash value field. The receiving end performs a SHA-256 hash operation on the concatenated message to be verified to obtain the hash value of the message to be verified. The receiving end then takes the hash value of the message to be verified, the sender's ECDSA digital signature, and the registered ECDSA verification public key as inputs to perform an ECDSA digital signature verification operation. The signature algorithm uses a secp256r1 elliptic curve. The verification process is as follows: the sender's ECDSA digital signature is parsed into signature values ​​r and s. It is verified whether both signature values ​​r and s are within the range from interval 1 to the order minus 1 of the elliptic curve. If either is outside the range, the signature verification result is invalid. If both are within the range, the public key point is recovered using the hash value of the message to be verified and signature values ​​r and s as inputs through elliptic curve dot product and modular inverse operations. The recovered public key point is compared with the coordinates of the registered ECDSA verification public key point. If the coordinates match, the signature verification result is valid; otherwise, the signature verification result is invalid. If the signature verification result is invalid, the data source authenticity verification is deemed to have failed. The encrypted data frame is discarded, and a signature verification failure event record is generated. The event record includes the sender's device identifier, timestamp, and hash value of the message to be verified, and is synchronized to the warehouse management system. If the signature verification result is valid, the data source authenticity verification is deemed to have passed, and the encrypted data frame is submitted to the B106 decryption process.

[0131] In this embodiment, ECDSA digital signature verification is used as the third and final layer of verification because it involves elliptic curve multiplication and modular inverse operations, which have the highest computational overhead among the three layers. The first two layers of verification have already filtered out illegal cross-regional access frames and frames from unregistered devices. ECDSA digital signature verification is only performed on ciphertext data frames that have passed the first two layers, minimizing the risk of high-overhead cryptographic operations being consumed by invalid frames. The signature verification covers all fields in the ciphertext data frame except for the sender's ECDSA digital signature field, including the ciphertext of the business data, the ciphertext of the session key, the first hash value, the second hash value, and the initialization vector—all fields that may be tampered with during transmission. Tampering with any field during transmission will change the hash value of the message to be verified, leading to signature verification failure, thus ensuring the authenticity of the data source and the integrity of all fields within the frame.

[0132] As a specific example, in this embodiment, a four-way AGV001 is deployed in storage area A3. Its storage area identifier is the string "A3". The original string of the device fingerprint is hashed using SHA-256 to obtain the device fingerprint digest. The receiving end is the storage gateway GW01, whose current access storage area identifier is A3. When AGV001 sends a encrypted data frame, it fills the sender's storage area identifier as A3 and the sender's device fingerprint as its original string in the frame header extension field. It also calculates an ECDSA digital signature for all fields in the frame except the signature field and fills it into the sender's ECDSA digital signature field. After receiving the frame, GW01 first extracts the sender's storage area identifier A3 and compares it byte by byte with the preset A3. If they match, the access scenario compliance verification is passed. Then, the original string of the sender's device fingerprint is extracted, and the SHA-256 hash value is calculated to obtain the receiver's device fingerprint digest. This digest is then matched against 32 records in the registered device fingerprint database. When a match is found for the record corresponding to AGV001, the XOR result of the 32 pairs of bytes is zero, indicating that the hardware legitimacy verification is successful. Finally, the registered ECDSA verification public key associated with AGV001 is used to perform a verification operation on the ECDSA digital signature within the frame. If the signature verification result is valid and the data source authenticity verification is successful, the encrypted data frame is submitted to the AES-GCM-256 decryption and authentication tag verification process.

[0133] It should be further explained that this embodiment performs segmented authentication and breakpoint resumption on unconfirmed data fragments, specifically including:

[0134] D201. Within each preset evaluation period, the receiver continuously sends M network probe messages to the sender, where M is an integer greater than or equal to three. It records the sending time T_send_i of the i-th network probe message and the receiving time T_recv_i of the corresponding response message. It calculates the arithmetic mean of the M network round-trip delay measurements within the preset evaluation period as the current network round-trip delay evaluation value, where the i-th network round-trip delay measurement value is equal to T_recv_i minus T_send_i.

[0135] In this embodiment, the preset evaluation period is set to 500 milliseconds, and M is set to five. At the beginning of each preset evaluation period, the receiver continuously sends five ICMP echo request messages as network probe messages to the transmitter via the wireless link, with a 100-millisecond interval between two adjacent network probe messages. The payload of each ICMP echo request message carries the transmitter device identifier, the current period sequence number, and the sequence number of the message within the period. After receiving the ICMP echo request message, the transmitter generates an ICMP echo response message within the hardware interrupt response time and immediately sends it back to the receiver. When the receiver sends the i-th network probe message, it reads the current count value of the hardware timer as the sending time T_send_i and temporarily stores this sending time in the probe record buffer within the hardware security module; when it receives the corresponding response message, it reads the current count value of the hardware timer as the receiving time T_recv_i, reads the corresponding T_send_i from the probe record buffer, and calculates the i-th network round-trip time measurement value as T_recv_i minus T_send_i. After all five network round-trip delay measurements are calculated within this period, the receiving end sums the five measurements and divides by five to obtain the current network round-trip delay assessment value.

[0136] In this embodiment, setting M to five and the preset evaluation period to 500 milliseconds is based on the following: In a 5G or Wi-Fi wireless communication environment, the multipath effect caused by the metal structure of the warehouse rack and the signal strength fluctuations caused by the rapid movement of the four-way vehicle will cause the single network round-trip delay measurement value to fluctuate drastically between 10 milliseconds and 200 milliseconds. If M is too small, the current network round-trip delay evaluation value may still be skewed by the occasional extreme jitter value, leading to a misjudgment of the true steady-state quality of the link. If M is too large, the evaluation period will be too long, resulting in a delayed response to policy switching, and segmented authentication cannot be triggered in time when the network condition has continued to deteriorate. With M set to five and the interval between adjacent probe packets being 100 milliseconds, the total evaluation period is 500 milliseconds. This time window can effectively smooth out single jitter through the five-sample averaging and can trigger policy switching after the network has continued to deteriorate for 500 milliseconds, thus balancing the stability of the evaluation and the response speed.

[0137] D202. Compare the current network round-trip latency assessment value with the preset latency threshold.

[0138] In this embodiment, the preset latency threshold is set to 80 milliseconds. This threshold is stored in the authentication policy configuration register within the receiver's hardware security module and is uniformly configured and issued by the warehouse management system based on the network topology and real-time operation requirements of the warehouse center during the system deployment initialization phase. The receiver performs a large integer comparison operation between the current network round-trip latency assessment value calculated by D201 and the preset latency threshold of 80 milliseconds.

[0139] The reason for setting the preset latency threshold to 80 milliseconds is as follows: In a normal, unobstructed warehouse wireless communication environment, the typical network round-trip latency between the four-way vehicle and the warehouse gateway is 15 to 40 milliseconds. When the network round-trip latency exceeds 80 milliseconds, it indicates that the transmission link has deteriorated significantly, possibly caused by factors such as metal shelving obstruction, signal interference from adjacent four-way vehicles, or congestion of the receiving end's computing resources. 80 milliseconds is twice the normal round-trip latency upper limit of 40 milliseconds. This value provides sufficient margin between normal fluctuations and abnormal deterioration, avoiding overreaction to occasional moderate delays of 50 to 70 milliseconds, while also triggering appropriate response strategies in a timely manner when the link does indeed deteriorate to above 80 milliseconds.

[0140] D203. If the current network round-trip delay assessment value is less than the preset delay threshold, the receiving end keeps the current session key unchanged and uses the session key to decrypt subsequently received ciphertext data frames.

[0141] In this embodiment, if the current network round-trip latency assessment value is 45 milliseconds, which is less than the preset latency threshold of 80 milliseconds, the receiving end determines that the network quality of the current transmission link is within an acceptable range and does not trigger an authentication policy change. The receiving end continues to use the negotiated session key to perform layered integrity verification and decryption operations (B106) on subsequently received ciphertext data frames, without needing to re-initiate authentication for the sending end. At the end of each preset assessment period, the receiving end re-executes D201 to D203 to achieve periodic monitoring of the network status and dynamic maintenance of the policy.

[0142] D204. If the current network round-trip delay assessment value is greater than or equal to the preset delay threshold, the receiving end reads the fragmentation acknowledgment bitmap of this session and determines whether there are bits marked as unacknowledged in the fragmentation acknowledgment bitmap.

[0143] In this embodiment, the fragmentation acknowledgment bitmap is a bit array stored in the session state record table within the receiver's hardware security module. The length of the fragmentation acknowledgment bitmap is equal to the total number of encrypted data frames sent by the sender in a single service data transmission. Each bit in the fragmentation acknowledgment bitmap corresponds to a data fragment. A bit value of 1 indicates that the data fragment has been correctly received by the receiver and has passed the layered integrity check (B106) and the device fingerprint verification (D103 to D105) and ECDSA digital signature verification. A bit value of 0 indicates that the data fragment has not yet been received by the receiver or has not passed the integrity check and authentication. After all data fragments have been sent, the sender sends the total number of data fragments to the receiver via a bitmap synchronization message. The receiver then initializes the fragmentation acknowledgment bitmap accordingly, with all bits initially set to zero.

[0144] When the current network round-trip time assessment value is greater than or equal to a preset delay threshold of 80 milliseconds, the receiving end reads the fragmented acknowledgment bitmap through the internal hardware bus and performs a logical OR operation on each bit of the fragmented acknowledgment bitmap. If all bits are in the acknowledged state (i.e., all have a value of 1), the result of the bitwise logical OR operation is 1. If any bit is in the unacknowledgment state (i.e., has a value of zero), the result of the bitwise logical OR operation is zero. However, the receiving end uses another independent bitwise logical AND operation to determine whether there is a bit with a value of zero. That is, it performs a logical AND operation on each bit of the fragmented acknowledgment bitmap. If the result of the logical AND operation is zero, it is determined that there is a bit marked as unacknowledgment.

[0145] D205. If all bits in the fragmentation confirmation bitmap are marked as confirmed, the receiver will keep the session key of the current session unchanged.

[0146] In this embodiment, if all bits in the fragmentation confirmation bitmap are one, it indicates that all data fragments transmitted by the sender in this transmission have been correctly received by the receiver and passed integrity verification and authentication. Although the current network round-trip time assessment value is greater than or equal to the preset delay threshold, the network degradation occurs after all data fragments have been correctly received. At this time, triggering segmentation authentication and retransmission will not improve data integrity; instead, it will waste computation and transmission resources due to unnecessary identity re-authentication and retransmission data processing. The receiver keeps the session key of the current session unchanged and destroys the session key normally according to the C104 procedure after the completion of this task, without sending a segmentation authentication request message to the sender.

[0147] Using the confirmation of all fragmented data fragments as the basis for not triggering segmented authentication is as follows: The purpose of segmented authentication is to re-authenticate and retransmit data fragments that failed to be received and verified due to network deterioration. If there are no unconfirmed data fragments, segmented authentication lacks a specific object to re-authenticate, and initiating segmented authentication would result in an empty process interaction between the receiver and sender without any actual data authentication content, unnecessarily increasing signaling overhead and authentication computational resource consumption. This judgment condition achieves conditional coupling between network state assessment results and actual data reception status, avoiding blind policy switching triggered by a single network state indicator.

[0148] D206. If there are bits marked as unacknowledged in the fragmentation confirmation bitmap, the receiver sends a fragmentation authentication request message to the sender. The fragmentation authentication request message carries the data fragment sequence number corresponding to the last bit marked as acknowledged. The sender takes the next data fragment with the data fragment sequence number as the starting fragment, and re-performs encryption and digital signature operations on the starting fragment and all subsequent fragments before sending them in sequence. The receiver performs device fingerprint verification and ECDSA digital signature verification on each re-received data fragment.

[0149] In this embodiment, after determining that there are unacknowledged bits in the fragment acknowledgment bitmap, the receiving end constructs a fragment authentication request message. This message includes a message type identifier field, a session identifier field, a last acknowledged fragment sequence number field, and a receiving end ECDSA digital signature field. The receiving end traverses the fragment acknowledgment bitmap from the highest bit to the lowest bit, finding the first bit with a value of 1, and uses the fragment sequence number corresponding to that bit as the value of the last acknowledged fragment sequence number field. If all bits in the fragment acknowledgment bitmap are zero, meaning no data fragment has been successfully acknowledged, the last acknowledged fragment sequence number field is filled with zero, indicating that the sending end should retransmit starting from the first data fragment. The receiving end performs an ECDSA digital signature operation on the concatenated data of the message type identifier field, session identifier field, and last acknowledged fragment sequence number field using the receiving end ECDSA digital signature private key pre-installed in the hardware security module. The signature result is filled into the receiving end ECDSA digital signature field, and the fragment authentication request message is sent to the sending end via the wireless link.

[0150] After receiving the segment authentication request message, the sending end first verifies the receiving end's ECDSA digital signature. Upon successful verification, it extracts the value of the last confirmed segment sequence number field and increments it by one to obtain the starting segment sequence number. The sending end reads the data segment corresponding to the starting segment sequence number and all subsequent segments from its local transmission buffer. For each data segment, it re-executes the complete encryption and framing process according to B101 to B105, including AES-GCM-256 encryption, RSA-2048 session key encryption, SHA-256 hash operation, and ciphertext data frame assembly. For each reassembled ciphertext data frame, it regenerates the ECDSA digital signature and fills it into the sender's ECDSA digital signature field in the frame header extension field before sending it sequentially to the receiving end. For each re-received ciphertext data frame, the receiving end verifies the sender's device fingerprint to confirm hardware legitimacy and verifies the ECDSA digital signature to confirm the authenticity of the data source, following the execution order of D101 to D105. After successful verification, it performs layered integrity verification and decryption according to B106.

[0151] In this embodiment, the reason for attaching an ECDSA digital signature to the segmented authentication request message by the receiving end is that the segmented authentication request directly determines which data fragments the sending end will retransmit. If an attacker forges a segmented authentication request message and carries a maliciously constructed sequence number of the last confirmed fragment, it may cause the sending end to skip the retransmission of some fragments or trigger unnecessary full retransmission. By attaching a digital signature to the segmented authentication request message by the receiving end, the sending end can verify the authenticity and integrity of the request.

[0152] As a specific example, in this embodiment, the sending end sends a total of eight data fragments, with fragment numbers from 0 to 7. The receiving end measures a network round-trip time (RTT) of 120 milliseconds within the current preset evaluation period, which is greater than the preset RTT threshold of 80 milliseconds, triggering a fragment acknowledgment bitmap check. In the fragment acknowledgment bitmap, the bits corresponding to fragment numbers 0 to 4 are set to 1, and the bits corresponding to fragment numbers 5 to 7 are set to 0. The receiving end traverses the fragment acknowledgment bitmap to obtain the last confirmed fragment with a sequence number of 4, constructs a segmented authentication request message, attaches an ECDSA digital signature, and sends it to the sending end. After verifying the signature, the sending end adds 1 to fragment number 4 to obtain the starting fragment number 5, and re-encrypts and signs the three unconfirmed fragments (fragment numbers 5, 6, and 7) before sending them sequentially. The receiving end verifies the device fingerprint and ECDSA digital signature of each of the re-received fragments five, six, and seven. After the verification is successful and the layer integrity check is successful, the corresponding bit in the fragment confirmation bitmap is updated to one, thus completing the segment authentication and breakpoint resume process.

[0153] It should be further explained that in this embodiment, the exception response module accumulates the number of consecutive hash verification failures and triggers session key renegotiation when the threshold is reached. Specifically, it includes the following steps:

[0154] E101. Set the hash check consecutive failure counter with an initial value of zero. Set the preset statistical period start time register and write the current time into the preset statistical period start time register.

[0155] In this embodiment, the exception response module allocates a 16-bit hash checksum failure counter and a 64-bit preset statistical period start time register within the hardware security module. The hash checksum failure counter is 16 bits wide and initialized to zero, indicating that no hash checksum failure event has occurred within the current statistical period. The preset statistical period start time register is 64 bits wide and stores a millisecond-level time value in Unix timestamp format. The current time is written to the register during receiver system initialization or at the end of the previous statistical period. Both the hash checksum failure counter and the preset statistical period start time register are stored in a protected memory area within the hardware security module. They can only be read and written atomically by the exception response module via the internal hardware bus; external processors and applications cannot directly access them.

[0156] The basis for setting the hash check consecutive failure counter width to 16 bits is that the preset number threshold is usually set to a small integer value, and the maximum counter value that 16 bits can represent is 65535, which is much larger than the actual number of consecutive failures that may be reached. At the same time, the 16-bit width can be implemented in the hardware security module with minimal area, and each increment and reset operation can be completed in a single clock cycle without introducing additional computational delay.

[0157] E102. After the receiving end receives a ciphertext data frame and completes the first hash value comparison and the second hash value comparison, if the first hash value comparison result is inconsistent or the second hash value comparison result is inconsistent, the hash verification continuous failure counter is incremented by one, the current value of the hash verification continuous failure counter is read, and the current value is compared with the preset number of times threshold.

[0158] In this embodiment, the receiving end performs layered integrity verification on each encrypted data frame in step B106. If the first hash value comparison result in step B106 is inconsistent (i.e., at least one bit is inconsistent between the first verification hash value independently calculated for the encrypted business data and the first hash value field carried in the frame), or if the second hash value comparison result in step B106 is inconsistent (i.e., at least one bit is inconsistent between the second verification hash value independently calculated for the encrypted session key and the second hash value field carried in the frame), the receiving end, after discarding the encrypted data frame, calls the interface of the exception response module in step B106 to trigger the update process of the hash verification continuous failure counter. The exception response module increments the hash verification continuous failure counter by one using an atomic addition operation via the internal hardware bus. After incrementing, it reads the current value of the counter and compares it with a preset threshold number of times.

[0159] In this embodiment, the preset threshold number is set to three. The rationale for setting the preset threshold number to three is as follows: In a warehouse wireless communication environment, the probability of a single wireless link bit error caused by multipath effects or momentary signal obstruction is approximately one in a thousand; the probability of two consecutive hash check failures is approximately one in a million; and the probability of three consecutive hash check failures caused by random link errors is approximately one in a billion, which is far lower than the system's acceptable false trigger probability. When an attacker systematically tampers with encrypted data frames, the tampered frames will continuously trigger hash check failures, and three consecutive failures can confirm the attack behavior in a short time. The value of three strikes a balance between the false trigger probability and the attack detection delay, controlling the false trigger probability caused by random link errors to a negligible level while confirming the attack's existence with the minimum number of frames after the attack is initiated, thus limiting the attacker's effective tampering window to within three frames.

[0160] E103. If the current value is equal to the preset number of times threshold, a session key renegotiation request is sent to the key negotiation module. The session key renegotiation request carries the sender device fingerprint. An abnormal event record is generated. The abnormal event record includes the sender device fingerprint field, the current value field of the hash check consecutive failure counter, and the current timestamp field. The abnormal event record is written to the security log storage area in the hardware security module, and the hash check consecutive failure counter is reset to zero.

[0161] In this embodiment, when the current value of the hash check consecutive failure counter is equal to a preset threshold of three, the exception response module performs the following three operations: First, it constructs a session key renegotiation request message, which includes a request type identifier field and a sender device fingerprint field. The request type identifier field is filled with a preset constant value to indicate the key renegotiation type triggered by an exception. The sender device fingerprint field is extracted from the frame header extension field of the currently received ciphertext data frame. The session key renegotiation request message is sent to the key negotiation module via the hardware internal bus. After receiving the request, the key negotiation module immediately executes the session key destruction process in steps C104 to C105, and executes a new round of session key negotiation process in steps A1021 to A106 with the current job task identifier as input. Second, it generates an exception event record, which includes a sender device fingerprint field, a consecutive failure count field, and a current timestamp field. The sender device fingerprint field is filled with the 256-bit value of the sender device fingerprint that triggered this renegotiation. The consecutive failure count field is filled with the current value of the hash check consecutive failure counter, which is three. The current timestamp field is filled with the current 64-bit millisecond-level Unix timestamp value of the hardware real-time clock. Third, the hash check consecutive failure counter is reset to zero via an atomic write operation through the internal hardware bus.

[0162] In this embodiment, abnormal event records are written to the security log storage area within the hardware security module. This security log storage area is a non-volatile storage region within the hardware security module, written append-only. Each abnormal event record occupies a fixed length and cannot be modified or deleted after being written. The rationale for using the non-volatile storage area within the hardware security module to record abnormal events is that attackers may attempt to clear or tamper with the security log through software means to cover up their attack after triggering key renegotiation. The security log storage area within the hardware security module is independent of the main processor and operating system, and the write operation is protected by hardware access control policies. Even if the operating system is compromised, attackers cannot modify or delete the written abnormal event records, ensuring the non-repudiation and integrity of the security audit data.

[0163] E104. If the current value is less than the preset number threshold, then read the time value in the preset statistical period start time register, calculate the difference between the current time and the time value, and compare the difference with the preset statistical period duration.

[0164] In this embodiment, if the current value of the hash check consecutive failure counter is one or two, which is less than the preset threshold of three, the exception response module does not immediately trigger session key renegotiation. Instead, it performs a statistical period timeout judgment. The exception response module reads the 64-bit Unix timestamp value from the preset statistical period start time register, reads the current 64-bit Unix timestamp value from the hardware real-time clock, and calculates the difference between the current time value and the start time value. This difference is an unsigned integer in milliseconds. The exception response module performs a large integer comparison operation between this difference and the preset statistical period duration.

[0165] In this embodiment, the preset statistical period is set to sixty seconds. The rationale for setting the preset statistical period to sixty seconds is as follows: During normal warehousing operations, hash verification failures are mainly caused by occasional random bit errors in the wireless link. The probability of this event is low, and the events are independent of each other. If the attacker does not continuously tamper with the communication link, the probability of two or more consecutive hash verification failures within a sixty-second statistical window is extremely low. If the attacker injects tampered frames intermittently, attempting to evade detection at frequencies below the threshold, a sixty-second period is sufficient to capture enough accumulations of low-frequency attack frames and trigger the threshold, preventing the attacker from circumventing key renegotiation by lengthening the attack interval. The sixty-second value also considers a trade-off between detection sensitivity and system stability. A period that is too short may cause the counter to reset before the occasional errors naturally disappear, reducing the detection capability for continuous low-frequency attacks; a period that is too long may cause the counter to retain historical failure records even after the attack has been blocked, with subsequent occasional errors superimposed on the residual count value, falsely triggering renegotiation.

[0166] E105. If the difference is greater than the preset statistical period duration, the hash verification consecutive failure counter is reset to zero, and the current time is written into the preset statistical period start time register; if the difference is less than or equal to the preset statistical period duration, the current value of the hash verification consecutive failure counter and the value of the preset statistical period start time register are kept unchanged.

[0167] In this embodiment, if the difference between the current time and the start time of the preset statistical period is greater than 60 seconds, it indicates that more than 60 seconds have passed since the start of the statistical period and the number of consecutive hash verification failures has not reached three. The consecutive failures within this period are more likely caused by occasional random link errors rather than persistent attacks. The anomaly response module resets the hash verification consecutive failure counter to zero, restarts the statistics for a new period, and writes the current time into the preset statistical period start time register to update the start time of the statistical period. If the difference is less than or equal to 60 seconds, it indicates that the current time is still within the time window of the statistical period. The anomaly response module keeps the current value of the hash verification consecutive failure counter and the value of the preset statistical period start time register unchanged, and continues to accumulate subsequent hash verification failure events.

[0168] The rationale for automatically resetting the counter upon statistical period timeout is as follows: the distribution of hash verification failures caused by occasional random link errors approximates a Poisson process over time, and the time interval between two failure events is usually quite long. Without setting a time window limit for the counter, the counter increment caused by an occasional error will remain permanently in the counter. Another occasional error occurring at any subsequent time point will be accumulated, potentially leading to the erroneous reaching of the preset threshold due to the accumulation of multiple occasional errors over a long period, triggering unnecessary session key renegotiation. By using a 60-second statistical period window, temporally unrelated occasional errors can be isolated within different statistical periods. Each statistical period starts counting independently from zero. Only when the number of consecutive failures within a statistical period reaches the threshold is it considered an attack, effectively distinguishing between occasional errors and persistent attacks.

[0169] As a specific example, in this embodiment, the receiving end sets the preset statistical period start time register to T0 at time T0, and the hash verification consecutive failure counter is initially set to zero. Ten seconds after T0, the receiving end receives the first ciphertext data frame with failed hash verification. The first hash value comparison result is inconsistent, and the counter increments by one to become one. The current value of one is less than the preset count threshold of three, and the difference between the current time and T0 is 10 seconds, which is less than 60 seconds. The counter and the start time remain unchanged. Twenty seconds after T0, the receiving end receives the second ciphertext data frame with failed hash verification. The second hash value comparison result is inconsistent, and the counter increments by one to become two. The current value of two is less than the preset count threshold of three, and the difference between the current time and T0 is 20 seconds, which is less than 60 seconds. The counter and the start time remain unchanged. At time T0 plus 25 seconds, the receiving end receives the third ciphertext data frame whose hash verification failed. The first hash value comparison result is inconsistent, and the counter is incremented by one to become three. The current value of three is equal to the preset count threshold of three. The anomaly response module sends a session key renegotiation request carrying the sender's device fingerprint to the key negotiation module, generates an anomaly event record containing the sender's device fingerprint, the consecutive failure count of three, and the current timestamp, and writes it to the security log storage area, resetting the counter to zero. If the first failure occurs at time T0 plus 10 seconds, and no second failure occurs by time T0 plus 70 seconds, and the difference between the current time and T0 is 70 seconds, which is greater than 60 seconds, the anomaly response module resets the counter from one to zero, updates the start time to T0 plus 70 seconds, and restarts a new cycle of statistics.

[0170] As a specific example of this embodiment, a complete scheduling operation of a large e-commerce smart warehouse center is used as an example to provide a written example description that combines specific values ​​and processes.

[0171] This intelligent warehousing center deploys 80 four-way vehicles, covering three different brands, and processes over 100,000 orders daily. The warehouse management system, shelf sensor cluster, sorting terminals, and warehouse gateway all utilize the warehousing business data encryption system based on a hybrid encryption architecture provided in this application.

[0172] In a certain operation, the warehouse management system issued a dispatch instruction to the four-way AGV-03, instructing it to move goods with the serial number SKU1234 from shelf A3. The operation task identifier was uniformly assigned by the warehouse management system as TASK-20260606-001.

[0173] First, the key negotiation process is executed. After the built-in encryption chip of the four-way AGV-03 completes its power-on self-test, it sequentially reads the CPU serial number A1B2C3D4E5F67890A1B2C3D4E5F67890 and the motherboard serial number 1234567890ABCDEF1234567890ABCDEF via the internal bus. It then obtains the operating system version number 4.19.75 and the kernel compilation identifier 4.19.75-001 through the system call interface. These four strings are concatenated with a vertical bar to obtain the original device fingerprint string. A SHA-256 hash operation is performed on this original device fingerprint string to obtain a 256-bit device fingerprint digest, which is stored in the one-time programmable memory area within the encryption chip.

[0174] The true random number generator within the hardware security module of the four-way AGV-03 generates a 256-bit random number. After passing non-zero checksum verification and secp256r1 elliptic curve order verification, this number is determined as the four-way vehicle's temporary private key. Using the secp256r1 elliptic curve standard generator as the base point, a scalar dot product operation is performed using the Montgomery step algorithm to obtain the four-way vehicle's temporary public key. This public key is encoded into 65 bytes in uncompressed dot format and encapsulated in a key negotiation request message, which is then sent in plaintext to the warehouse gateway via the 5G wireless link. The message also carries the four-way vehicle device identifier AGV-03. After transmission, the four-way vehicle starts a key negotiation response timer with a timeout period set to 2 seconds.

[0175] After receiving the key negotiation request message, the warehouse gateway queries the registered device fingerprint database using device identifier AGV-03 as the index. The registered device fingerprint database stores the device fingerprint digest corresponding to AGV-03 and the registered ECDSA verification public key. After confirming that AGV-03 is a registered device, the warehouse gateway calls the true random number generator within the hardware security module to generate a temporary private key. After passing the same non-zero checksum and order check, a Montgomery stepwise multiplication operation is performed using the same elliptic curve generator as the base point to obtain the temporary public key. The warehouse gateway then performs an ECDSA digital signature operation on the concatenated data of the message type identifier field, warehouse gateway device identifier field, four-way vehicle device identifier field, session identifier field, temporary public key length field, and temporary public key data field in the response message using the gateway ECDSA digital signature private key. After filling the signature value into the digital signature field, the key negotiation response message is sent to the four-way vehicle AGV-03.

[0176] After receiving the response message, the four-way AGV-03 first verifies the ECDSA digital signature of the warehouse gateway. Upon successful signature verification, it performs a Montgomery stepwise multiplication operation using the four-way AGV's temporary private key and the gateway's temporary public key, extracting the x-coordinate of the result point to obtain a 256-bit shared secret. Upon receiving the key negotiation confirmation message from the four-way AGV, the warehouse gateway performs the same multiplication operation using its temporary private key and the four-way AGV's temporary public key, obtaining the same 256-bit shared secret. Both parties concatenate the shared secret in the high-order bits and the device fingerprint digest in the low-order bits to form a 512-bit concatenation result. Using a preset 128-bit fixed salt value and the job task identifier TASK-20260606-001 as info parameters, the result undergoes HMAC-SHA256 operations once each during the extraction and expansion phases of the HKDF, generating a 256-bit session key. The session key is written into the session key register within each hardware security module and bound to the job task identifier TASK-20260606-001.

[0177] After key negotiation, the warehouse management system sends the scheduling instruction to the warehouse gateway in plaintext. The warehouse gateway's encryption framing module encrypts the scheduling instruction body using the AES-GCM-256 algorithm. In the first parallel branch, the AES-GCM-256 encryption engine uses the session key as the encryption key to generate a 96-bit random initialization vector. It then performs 14 rounds of encryption transformation on the scheduling instruction body in 128-bit blocks, outputting the ciphertext of the scheduling instruction and a 128-bit first authentication tag. The ciphertext is then independently hashed using SHA-256, outputting a 256-bit first hash value. Simultaneously, in the second parallel branch, the session key is encrypted using the warehouse gateway's pre-configured RSA-2048 public key and the RSAES-OAEP padding scheme, outputting a 256-byte ciphertext of the session key. The ciphertext is then independently hashed using SHA-256, outputting a 256-bit second hash value. The above fields are assembled into a encrypted data frame according to a preset frame structure, including a frame header identifier field, a frame sequence number field, an initialization vector field, a scheduling instruction encrypted field, a first authentication tag field, a first hash value field, a session key encrypted field, and a second hash value field. The sender's warehouse area identifier A3, the sender's device fingerprint raw string, and the sender's ECDSA digital signature are filled into the frame header extension field. The encrypted data frame is transmitted to the four-way AGV-03 via a wireless link.

[0178] After receiving the encrypted data frame, the four-way AGV-03 performs layered authentication. First, it extracts the sender's storage area identifier A3 and compares it byte-by-byte with the preset currently accessed storage area identifier A3. If the comparison result is consistent, the access scenario compliance verification passes. Next, it extracts the sender's device fingerprint raw string, calculates the SHA-256 hash value to obtain the receiver's device fingerprint digest, and matches it byte-by-byte with the device fingerprint digest corresponding to AGV-03 in the registered device fingerprint database. If the match is successful, the hardware legitimacy verification passes. Finally, using the registered ECDSA verification public key associated with AGV-03, it calculates the hash value of the message to be verified for all remaining fields in the encrypted data frame after excluding the sender's ECDSA digital signature field, and performs ECDSA digital signature verification. If the signature verification result is valid, the data source authenticity verification passes. After all three layers of authentication pass, the four-way AGV-03 performs layered integrity verification. First, calculate the SHA-256 hash value of the ciphertext of the dispatch instruction and compare it with the first hash value within the frame; the comparison is successful. Then, calculate the SHA-256 hash value of the ciphertext of the session key and compare it with the second hash value within the frame; the comparison is successful. Use the warehouse gateway's RSA-2048 private key to decrypt the ciphertext of the session key to obtain the plaintext of the session key. Use the plaintext of the session key and the initialization vector to perform AES-GCM-256 decryption and authentication tag verification on the ciphertext of the dispatch instruction. If the authentication tag verification passes, the plaintext of the dispatch instruction is obtained, which is to proceed to shelf A3 area to move goods with the number SKU1234.

[0179] After executing the scheduling command, the four-way AGV-03 generates an encrypted data frame using the same encryption framing process and sends it to the warehouse gateway. The warehouse gateway then decrypts the data frame using the same three-layer authentication and layered integrity verification process to obtain the execution result and forwards it to the warehouse management system.

[0180] During transmission, the network experienced momentary signal attenuation due to obstruction by a metal shelf. Within a preset 500ms evaluation period, the receiver continuously sent five ICMP echo request messages to the sender, measuring five network round-trip times (RTCs) of 95ms, 110ms, 130ms, 125ms, and 115ms respectively. The arithmetic mean of these five RTCs yielded an estimated current RTC of 115ms. This value exceeds the preset delay threshold of 80ms. The receiver reads the fragmentation acknowledgment bitmap for this session. The fragmentation acknowledgment bitmap consists of eight bits, corresponding to fragment sequence numbers 0 to 7. Bits corresponding to fragment sequence numbers 0 to 4 are set to 1, while bits corresponding to fragment sequence numbers 5 to 7 are set to 0. The receiver determines the presence of unacknowledged data fragments, constructs a fragmentation authentication request message, fills the last acknowledged fragment sequence number field with 4, attaches the receiver's ECDSA digital signature, and sends it to the sender. After the sender verifies the signature, it retransmits fragments five, six, and seven, starting with fragment number five, by performing AES-GCM-256 encryption, RSA-2048 session key encryption, SHA-256 hashing, and ECDSA digital signature. The receiver then verifies the device fingerprint and ECDSA digital signature on each of the three retransmitted fragments. Once verification and layered integrity verification are successful, the receiver updates the corresponding bit in the fragment confirmation bitmap to one, completing the resume transmission.

[0181] At another moment, within a preset statistical period of sixty seconds, the receiving end receives three consecutive encrypted data frames from the same sender, and their first hash values ​​are inconsistent. The hash verification consecutive failure counter increments by one to three sequentially from its initial value of zero. When the current value of the counter equals a preset threshold of three, the anomaly response module determines that a persistent data tampering attack exists, immediately sends a session key renegotiation request carrying the sender's device fingerprint to the key negotiation module, generates an anomaly event record, and writes the record, which includes the sender's device fingerprint (256 bits), the consecutive failure count of three, and the current millisecond-level Unix timestamp, to the non-volatile security log storage area within the hardware security module, and resets the counter to zero. Upon receiving the renegotiation request, the key negotiation module executes the session key destruction process, overwriting the current session key register with all zeros, and triggers a new round of key negotiation process using the current job task identifier as input. The anomaly event record in the security log storage area is periodically synchronized to the blockchain evidence storage platform by the warehouse management system, supporting traceability auditing by device identifier and time range, meeting the Level 3 compliance requirements of the information security protection system.

[0182] Example 3

[0183] Please see Figure 4 Another embodiment of the present invention provides: a warehouse business data encryption system based on a hybrid encryption architecture, comprising:

[0184] S1. Extract the device fingerprint of the four-way vehicle, which consists of a hardware serial number and operating system characteristics; using the device fingerprint and the public key of the warehouse gateway as input, generate a session key through the improved Diffie-Hellman protocol, and associate the session key with the current job task identifier; in response to the change of the job task identifier or the job completion signal, destroy the session key.

[0185] S2. Encrypt the business data body with the AES-GCM-256 algorithm, encrypt the session key with the RSA-2048 algorithm, calculate the SHA-256 hash value of the encrypted business data body, and assemble the real-time position coordinates of the four-way vehicle, the encrypted business data body, the encrypted session key and the SHA-256 hash value into a ciphertext data frame and send it.

[0186] S3. Receive the encrypted data frame, extract the device fingerprint to verify hardware legitimacy, verify the ECDSA digital signature to confirm the authenticity of the data source, extract the warehouse area identifier to confirm the compliance of the access scenario; obtain the network round-trip latency, maintain session reuse when the network round-trip latency is less than a preset latency threshold, and perform segmented authentication and breakpoint resumption on unconfirmed data fragments when the network round-trip latency is greater than or equal to the preset latency threshold.

[0187] S4. Accumulate the number of consecutive failures of SHA-256 hash verification within the statistical period. When the number of consecutive failures reaches a preset threshold, trigger the renegotiation of the session key and generate an event record containing the device fingerprint and the number of consecutive failures.

[0188] Example 3

[0189] An electronic device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement a method for encrypting warehouse business data based on a hybrid encryption architecture.

[0190] A computer-readable storage medium storing computer instructions that, when executed, perform a method for encrypting warehouse business data based on a hybrid encryption architecture.

[0191] The embodiments of the present invention have been described above with reference to the accompanying drawings. However, the present invention is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments under the guidance of the present invention without departing from the spirit and scope of the present invention. All of these variations are within the scope of protection of the present invention.

[0192] If the technical solution disclosed herein involves personal information, the product using this technical solution has clearly informed the user of the personal information processing rules and obtained the user's voluntary consent before processing the personal information. If the technical solution disclosed herein involves sensitive personal information, the product using this technical solution has obtained the user's separate consent before processing the sensitive personal information, and also meets the requirement of "express consent". For example, at personal information collection devices such as cameras, clear and prominent signs are set up to inform users that they have entered the scope of personal information collection and that personal information will be collected. If an individual voluntarily enters the collection scope, it is deemed that they have agreed to the collection of their personal information; or on the personal information processing device, with clear signs / information informing users of the personal information processing rules, authorization is obtained from the individual through pop-up information or by asking the individual to upload their personal information; wherein, the personal information processing rules may include information such as the personal information processor, the purpose of personal information processing, the processing method, and the types of personal information processed.

Claims

1. A warehouse business data encryption system based on a hybrid encryption architecture, characterized in that: include: The key negotiation module is configured to: extract the device fingerprint of the four-way vehicle, the device fingerprint consisting of a hardware serial number and operating system characteristics; use the device fingerprint and the public key of the warehouse gateway as input to generate a session key through an improved Diffie-Hellman protocol, associate the session key with the current job task identifier, and destroy the session key in response to a change in the job task identifier or a job completion signal; The encryption framing module is configured to: encrypt the service data body with the AES-GCM-256 algorithm, encrypt the session key with the RSA-2048 algorithm, calculate the SHA-256 hash value of the encrypted service data body, and assemble the real-time position coordinates of the four-way vehicle, the encrypted service data body, the encrypted session key, and the SHA-256 hash value into a ciphertext data frame and send it. The multi-factor authentication module is configured to: receive the encrypted data frame, extract the device fingerprint to verify the legality of the hardware, verify the ECDSA digital signature to confirm the authenticity of the data source, and extract the warehouse area identifier to confirm the compliance of the access scenario. The network round-trip time is obtained. When the network round-trip time is less than a preset time threshold, session reuse is maintained. When the network round-trip time is greater than or equal to the preset time threshold, segmented authentication and breakpoint resumption are performed on unconfirmed data fragments. The exception response module is configured to: accumulate the number of consecutive failures of SHA-256 hash verification within a statistical period; when the number of consecutive failures reaches a preset threshold, trigger the renegotiation of the session key and generate an event record containing the device fingerprint and the number of consecutive failures.

2. The warehousing business data encryption system based on a hybrid encryption architecture as described in claim 1, characterized in that, The device fingerprint also includes at least one of the following: the MAC address of the four-way vehicle's network card, the unique identifier of the security chip, or the endorsement key of the Trusted Platform Module (TPM); the hardware serial number includes at least one of the following: the CPU serial number, the motherboard serial number, or the storage module serial number; the generation of the session key through the improved Diffie-Hellman protocol includes: Perform a hash operation on the extracted device fingerprint to obtain a device fingerprint digest; On the elliptic curve domain, the four-way vehicle generates a temporary private key, and performs a dot product operation on the temporary private key using the elliptic curve base points to obtain a temporary public key for the four-way vehicle, and sends the temporary public key for the four-way vehicle to the warehouse gateway. The warehouse gateway generates a temporary private key and performs a dot product operation on the temporary private key using the elliptic curve base points to obtain a temporary public key, which is then sent to the four-way vehicle.

3. The warehousing business data encryption system based on a hybrid encryption architecture as described in claim 2, characterized in that, The generation of session keys via the improved Diffie-Hellman protocol also includes: The four-way vehicle performs a dot product operation between its temporary private key and the temporary public key of the gateway to obtain a first shared secret, and the warehouse gateway performs a dot product operation between its temporary private key and the temporary public key of the four-way vehicle to obtain a second shared secret. The first shared secret and the second shared secret are concatenated with the device fingerprint digest to obtain the first concatenated secret and the second concatenated secret; The first concatenated secret and the second concatenated secret are input into the hash-based message authentication code key derivation function to generate the session key, so that the session key is simultaneously bound to the shared secret and the device fingerprint of the four-way vehicle.

4. The warehousing business data encryption system based on a hybrid encryption architecture as described in claim 3, characterized in that, The calculation of the SHA-256 hash value for the encrypted business data body includes: The main body of the business data to be transmitted and the currently valid session key are taken as inputs and sent to the first parallel branch and the second parallel branch respectively. In the first parallel branch, the business data subject and the session key are taken as input, encrypted by the AES-GCM-256 algorithm, and the business data ciphertext, the first authentication tag and the initialization vector are output. The business data ciphertext is then hashed independently to output the first hash value.

5. The warehousing business data encryption system based on a hybrid encryption architecture as described in claim 4, characterized in that, The calculation of the SHA-256 hash value for the encrypted business data subject also includes: In the second parallel branch, it is executed synchronously with the first parallel branch. It takes the session key and the preset warehouse gateway public key as input, encrypts them using the RSA-2048 algorithm, outputs the session key ciphertext, and independently performs a hash operation on the session key ciphertext to output the second hash value. The encrypted business data, the first authentication tag, the initialization vector, the first hash value, the encrypted session key, and the second hash value are taken as input, assembled into an encrypted data frame according to a preset frame structure, and output and sent to the receiving end.

6. The warehousing business data encryption system based on a hybrid encryption architecture as described in claim 5, characterized in that, The step of destroying the session key in response to a change in the job task identifier or a job completion signal includes: A session key usage counter is set, with an initial value of zero. Each time the encryption framing module starts to perform an encryption operation on a frame of service data body with the current session key, the session key usage counter is incremented by one. Each time the encryption operation on a frame of service data body is completed and the ciphertext data frame is output, the session key usage counter is decremented by one. Receive a task identifier change signal or task completion signal issued by the warehouse management system, read the current value of the session key usage counter, and determine whether the current value is equal to zero.

7. The warehousing business data encryption system based on a hybrid encryption architecture as described in claim 6, characterized in that, The step of destroying the session key in response to a change in the job task identifier or a job completion signal further includes: If the current value is not equal to zero, it is determined that the current session key still has at least one frame of business data in the encryption process. The job task identifier change signal or job completion signal is temporarily stored, and the session key usage counter is continuously polled until the current value is equal to zero. Then, a session key destruction command is sent to the hardware security module to overwrite the session key register with all zeros and release the association between the current session key and the job task identifier. If the current value is equal to zero, it is determined that there is no encryption operation in transit for the current session key. A session key destruction command is immediately sent to the hardware security module to overwrite the session key register with all zeros and release the association between the current session key and the job task identifier.

8. The warehousing business data encryption system based on a hybrid encryption architecture as described in claim 7, characterized in that, Extracting the device fingerprint to verify hardware legitimacy, verifying the ECDSA digital signature to confirm the authenticity of the data source, and extracting the warehouse area identifier to confirm the compliance of the access scenario, including: The receiving end extracts the sender's warehouse area identifier field, the sender's device fingerprint field, and the sender's ECDSA digital signature field from the frame header extension field of the encrypted data frame; The sender's storage area identifier is compared byte by byte with the currently accessed storage area identifier preset in the receiver's hardware security module. If the comparison result is inconsistent, the encrypted data frame is discarded and the authentication process is terminated. If the comparison results are consistent, the sender device fingerprint is compared byte by byte with each registered device fingerprint stored in the registered device fingerprint database. If the comparison results of the sender device fingerprint with all registered device fingerprints are inconsistent, the encrypted data frame is discarded and the authentication process is terminated.

9. The warehousing business data encryption system based on a hybrid encryption architecture as described in claim 8, characterized in that, Extracting the device fingerprint to verify hardware legitimacy, verifying the ECDSA digital signature to confirm the authenticity of the data source, and extracting the warehouse area identifier to confirm the compliance of the access scenario, also includes: If the comparison result between the sender's device fingerprint and a registered device fingerprint is consistent, the registered ECDSA verification public key associated with that registered device fingerprint is read from the registered device fingerprint database. A byte string formed by concatenating all remaining fields in the ciphertext data frame after excluding the sender's ECDSA digital signature field is used as the message to be verified. A SHA-256 hash value is calculated for the message to be verified. Using the SHA-256 hash value, the sender's ECDSA digital signature, and the registered ECDSA verification public key as inputs, an ECDSA digital signature verification operation is performed. If the signature verification result is invalid, the ciphertext data frame is discarded and a signature verification failure event record is generated; if the signature verification result is valid, the ciphertext data frame is submitted to the decryption process.

10. A method for encrypting warehouse business data based on a hybrid encryption architecture, implemented based on the warehouse business data encryption system based on a hybrid encryption architecture as described in any one of claims 1-9, characterized in that... include: Extract the device fingerprint of the four-way vehicle, which consists of a hardware serial number and operating system characteristics; use the device fingerprint and the public key of the warehouse gateway as input to generate a session key through an improved Diffie-Hellman protocol, and associate the session key with the current job task identifier; in response to a change in the job task identifier or a job completion signal, destroy the session key. The service data body is encrypted with the AES-GCM-256 algorithm, the session key is encrypted with the RSA-2048 algorithm, the SHA-256 hash value is calculated on the encrypted service data body, and the real-time position coordinates of the four-way vehicle, the encrypted service data body, the encrypted session key and the SHA-256 hash value are assembled into a ciphertext data frame and sent. The encrypted data frame is received, the device fingerprint is extracted to verify the legality of the hardware, the ECDSA digital signature is verified to confirm the authenticity of the data source, and the warehouse area identifier is extracted to confirm the compliance of the access scenario. The network round-trip time is obtained. When the network round-trip time is less than a preset time threshold, session reuse is maintained. When the network round-trip time is greater than or equal to the preset time threshold, segmented authentication and breakpoint resumption are performed on unconfirmed data fragments. The cumulative number of consecutive failures of SHA-256 hash verification within the statistical period is counted. When the number of consecutive failures reaches a preset threshold, the session key is renegotiation is triggered, and an event record containing the device fingerprint and the number of consecutive failures is generated.

Images