Dynamic key agreement system and method based on improved diffie-hellman

Abstract

The application belongs to the field of communication security, and particularly relates to a dynamic key agreement system and method based on improved Diffie-Hellman, which comprises the following steps: when network switching is triggered, a first negotiation unit compares a target warehouse gateway with a current trust domain identifier; if they are consistent, the current session key and a freshness factor are encrypted by a gateway public key and sent, and a second negotiation unit decrypts the response message by the current session key and encrypts and issues a new session key, so that lightweight key migration is realized; if they are inconsistent, the security context is cleared and a complete improved Diffie-Hellman negotiation process is triggered, that is, a shared secret is calculated based on a device fingerprint digest and an elliptic curve DH, and the shared secret and the fingerprint digest are spliced and then a new session key is generated through key derivation. According to the application, the negotiation intensity is adaptively switched according to the change of the trust domain, so that the key agreement overhead and business interruption delay caused by network switching are greatly reduced while the security is ensured.

Description

Technical Field

[0001] This invention belongs to the field of communication security, and particularly relates to a dynamic key negotiation system and method based on an improved Diffie-Hellman approach. Background Technology

[0002] In the field of intelligent warehousing and logistics, four-way shuttles (hereinafter referred to as "four-way shuttles") are core handling equipment that needs to perform high-frequency handling and retrieval operations in the high-density storage aisles of automated racking systems. During their operation, they need to continuously and in real-time exchange data with the warehouse management system (WMS), warehouse gateways, and other automated equipment, including scheduling instructions, cargo information, location coordinates, and equipment status. The confidentiality, integrity, and authenticity of such business data directly determine the continuity of warehousing operations and asset security. Under the continuous high-speed movement and cross-regional switching conditions of the four-way shuttle, its communication link frequently jumps between wireless access points (APs), exhibiting highly dynamic and unstable communication connections.

[0003] Before establishing secure data communication, both parties must dynamically generate a temporary session key over an insecure public channel through a key negotiation protocol. This process is the primary prerequisite for ensuring communication security. However, existing key negotiation schemes exhibit significant efficiency and reliability deficiencies when faced with the unique dynamic nature of four-way vehicle warehousing scenarios.

[0004] A classic key exchange scheme is the traditional Diffie-Hellman (DH) protocol and its elliptic curve-based variant (ECDH). Both parties exchange temporary public keys and independently compute a shared secret based on their own private keys and the other party's public key. However, the standard DH protocol itself does not provide authentication capabilities for the communicating parties, making it highly vulnerable to man-in-the-middle attacks. When a four-way vehicle connects to a new warehouse gateway, an attacker can easily impersonate a legitimate gateway or four-way vehicle, intercepting and tampering with communication content. To improve security, digital certificate systems are typically used for authentication, but this requires the pre-deployment of a complex public key infrastructure (PKI). In scenarios with a large number of four-way vehicles, mixed use of heterogeneous devices from multiple brands, and frequent cross-network segment access, the full lifecycle management of certificates (issuance, renewal, revocation, and verification) incurs extremely high operational costs and computational overhead. The latency introduced during online certificate verification is unacceptable for real-time scheduling instructions that are extremely sensitive to latency.

[0005] Another approach focuses on reducing the communication complexity and number of rounds in key negotiation. For example, patent application CN117254903A discloses a key negotiation method and system. In this approach, the requester generates a temporary key, encrypts it with the other party's public key, and broadcasts it. The responder decrypts the temporary key, uses it as the message authentication key, and returns it after encrypting the session key. While this method reduces the number of communication rounds and provides message authentication, its core mechanism relies on the requester's static first message, which cannot handle real-time changes in the responder's identity. In a warehousing scenario, when a four-way vehicle switches to a new warehousing gateway coverage area due to movement, it must re-execute the complete key negotiation process. This approach does not provide a mechanism that allows the four-way vehicle to "quickly" or "seamlessly" migrate or update its session key using existing trust relationships with previous gateways or other gateways within the same trust domain. This results in a complete key negotiation signaling interaction involving asymmetric encryption operations for each network switch, causing significant computational latency and signaling overhead.

[0006] Another approach focuses on integrating quantum-resistant algorithms into the key negotiation process to improve long-term security. For example, Chinese patent CN116582265B discloses a key negotiation method and system that incorporates elements generated using the NTRU algorithm into the key negotiation elements generated by the SM2 algorithm to ensure forward security. This approach addresses the potential threat of quantum computing to future communication security, but it does not address the negotiation efficiency under dynamic network topology changes. Its algorithm selection is aimed at countering specific cryptanalysis models, rather than optimizing the negotiation protocol's response speed and robustness to dynamic network conditions. In environments where four-way vehicles frequently switch access points, directly applying such computationally more complex quantum-resistant key negotiation algorithms could actually exacerbate the communication interruption during network switching due to increased computation time, thus reducing system throughput.

[0007] Therefore, in warehousing scenarios involving high-speed movement of four-way vehicles and cross-regional operations, the key technical problem that existing technologies urgently need to solve is how to achieve a dynamic key negotiation mechanism that can sense dynamic changes in communication connections and adaptively adjust negotiation strategies while ensuring the security of key negotiation. This would overcome the huge signaling overhead and service interruption delays caused by frequent full renegotiation due to network switching, while avoiding rigid dependence on complex centralized certificate verification systems, and achieving efficiency and robustness in the key negotiation process. Summary of the Invention

[0008] To address the shortcomings of existing technologies, this invention proposes a dynamic key negotiation system and method based on an improved Diffie-Hellman algorithm, comprising a first negotiation unit on the vehicle side and a second negotiation unit on the gateway side. When a network handover is triggered, the first negotiation unit compares the target warehouse gateway with the current trust domain identifier. If they match, the current session key and freshness factor are encrypted using the gateway's public key and sent. The second negotiation unit decrypts the encrypted message, authenticates the response message using the current session key, and encrypts and sends a new session key, achieving lightweight key migration. If they do not match, the security context is cleared and the complete improved Diffie-Hellman negotiation process is triggered. This involves calculating a shared secret based on the device fingerprint digest and elliptic curve DH, concatenating the shared secret with the fingerprint digest, and generating a new session key through key derivation. This invention adaptively switches the negotiation strength according to changes in the trust domain, significantly reducing key negotiation overhead and service interruption latency caused by network handover while ensuring security.

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

[0010] The system is based on an improved Diffie-Hellman dynamic key negotiation system, including a first negotiation unit deployed on a four-way vehicle and a second negotiation unit deployed on a warehouse gateway.

[0011] The first negotiation unit is configured to, when the four-way vehicle triggers a network switching event, obtain the trust domain identifier of the target warehouse gateway and compare it with the current trust domain identifier stored locally; if the trust domain identifiers are consistent, obtain a valid current session key, encrypt the current session key and the generated first freshness factor with the public key of the target warehouse gateway, construct a first ciphertext carrying a renegotiation marker and send it.

[0012] The second negotiation unit is configured to receive the first ciphertext, identify the renegotiation marker, decrypt it using its own private key to obtain the current session key and the first freshness factor, use the current session key as the key for the message authentication code, generate the first ciphertext and the second ciphertext containing the new session key, and send a response message containing the message authentication code and the second ciphertext.

[0013] The first negotiation unit is further configured to receive the response message, verify the validity of the message authentication code based on the current session key, and if valid, decrypt the second ciphertext to obtain a new session key and replace the current session key;

[0014] The first negotiation unit is also configured to: if the trust domain identifiers are inconsistent, clear the session key and key parameters associated with the current trust domain in the local security context, and initiate a complete Diffie-Hellman key negotiation process based on the device fingerprint and the gateway public key.

[0015] Specifically, when a four-way vehicle triggers a network switching event, the trust domain identifier of the target warehouse gateway is obtained, including:

[0016] When the first negotiation unit detects that the signal strength value of the current access link is continuously lower than a preset threshold value and the duration reaches a preset duration, it determines that a network handover event is triggered and starts a collection window with a duration of a preset collection duration.

[0017] Within the acquisition window, the first negotiation unit sequentially receives N beacon frames broadcast by the target warehouse gateway, extracts the candidate trust domain identifier field from the extended area information element of each beacon frame, and records the received signal strength indication value corresponding to the beacon frame, thereby obtaining a one-to-one correspondence between the N candidate trust domain identifiers and the N received signal strength indication values.

[0018] The N candidate trust domain identifiers are deduplicated to obtain M different candidate trust domain identifiers.

[0019] Specifically, when a four-way vehicle triggers a network switching event, obtaining the trust domain identifier of the target warehouse gateway also includes:

[0020] For each different candidate trust domain identifier, count the number of times it appears in the N candidate trust domain identifiers, and take the arithmetic mean of all the received signal strength indication values ​​corresponding to the candidate trust domain identifier to obtain the average signal strength value corresponding to the candidate trust domain identifier.

[0021] The candidate trust domain identifier whose ratio of occurrence to N exceeds a preset ratio threshold and whose average signal strength value is the largest is determined as the trust domain identifier of the target warehouse gateway, and the trust domain identifier is compared byte by byte with the current trust domain identifier stored in the local security storage area.

[0022] If the comparison results are consistent, it is determined that this network handover is an intra-domain handover, and the step of obtaining a valid current session key is executed;

[0023] If the comparison results are inconsistent, it is determined that this network switch is a cross-domain switch, the current switch process is terminated, and the process waits for the next acquisition window to reacquire the trusted domain identifier.

[0024] Specifically, the process of generating the first freshness factor includes:

[0025] The first negotiation unit reads the key identifier corresponding to the current session key stored in the local secure storage area. The key identifier is an 8-byte random number generated by the second negotiation unit and sent back to the first negotiation unit through the response message during the complete Diffie-Hellman key negotiation process.

[0026] The first negotiation unit reads the lightweight negotiation counter that is locally maintained and bound to the current session key, performs an atomic increment operation on the lightweight negotiation counter, and determines the incremented count value as the negotiation sequence number of this negotiation.

[0027] Specifically, the generation process of the first freshness factor also includes:

[0028] The first negotiation unit concatenates the 8 bytes of the key identifier, the 4 bytes of the negotiation sequence number (big-endian unsigned integer feature), and the trust domain identifier in the order of key identifier first, negotiation sequence number in the middle, and trust domain identifier last to form a byte string to be derived. The 256 bits of the current session key are used as the key for HMAC-SHA256 operation, and the byte string to be derived is used as the message for HMAC-SHA256 operation. The HMAC-SHA256 operation is performed to obtain a 256-bit output value, and the first 16 bytes of the output value are taken as the first freshness factor.

[0029] Specifically, encrypting the current session key and the generated first freshness factor using the target warehouse gateway's public key includes:

[0030] The first negotiation unit reads the target warehouse gateway public key, which has a mapping relationship with the trust domain identifier, from the local secure storage area. The target warehouse gateway public key is the RSA-2048 public key distributed by the second negotiation unit during the device registration phase. The first negotiation unit also reads the public key fingerprint value stored in association with the target warehouse gateway public key. The public key fingerprint value is a 32-byte hash value obtained by performing a SHA-256 hash operation on all bytes of the 294-byte DER encoded data of the target warehouse gateway public key.

[0031] The first negotiation unit uses 32 bytes of the current session key as the key for HMAC-SHA256 operation and 16 bytes of the first freshness factor as the message for HMAC-SHA256 operation. It performs HMAC-SHA256 operation to obtain a 32-byte output value and takes the first 8 bytes of the 32-byte output value as the public key binding verification code.

[0032] Specifically, encrypting the current session key and the generated first freshness factor using the target warehouse gateway's public key also includes:

[0033] The first negotiation unit concatenates the 16 bytes of the first freshness factor, the 8 bytes of the public key binding verification code, and the 32 bytes of the current session key in the order of the first freshness factor first, the public key binding verification code in the middle, and the current session key last to form a 56-byte payload to be encrypted. Using the target warehouse gateway public key as the encryption key, the RSAES-OAEP algorithm with SHA-256 padding scheme is used to perform RSA-2048 encryption operation on the 56-byte payload to be encrypted to obtain a 256-byte payload ciphertext.

[0034] The first negotiation unit concatenates the 32 bytes of the public key fingerprint value, the 256 bytes of the payload ciphertext, and the 1 byte of the renegotiation flag into a 289-byte first ciphertext in the order of the public key fingerprint value first, the payload ciphertext in the middle, and the renegotiation flag last, and sends the first ciphertext to the second negotiation unit.

[0035] Specifically, generating the message authentication code that includes the first ciphertext and the second ciphertext containing the new session key includes:

[0036] Read the 289th byte of the first ciphertext, compare the value of the 289th byte with the preset renegotiation type constant value 0x01, and if the comparison result is not equal, discard the first ciphertext and terminate the process.

[0037] If the comparison result is equal, then read bytes 1 to 32 of the first ciphertext as the public key fingerprint value of the receiving side, read the public key fingerprint value of itself stored in the local secure storage area, and perform an XOR operation byte by byte between the 32 bytes of the public key fingerprint value of the receiving side and the 32 bytes of the public key fingerprint value of itself. If the XOR result of any byte is not zero, then it is determined that the public key fingerprint values ​​do not match, the first ciphertext is discarded and the processing is terminated.

[0038] Specifically, generating the message authentication code that includes the first ciphertext and the second ciphertext containing the new session key also includes:

[0039] If the XOR result of all 32 bytes is zero, the second negotiation unit reads bytes 33 to 288 of the first ciphertext as the payload ciphertext, uses its own stored RSA-2048 private key as the decryption key, and uses SHA-256 as the OAEP hash function to perform RSAES-OAEP decryption operation on the 256-byte payload ciphertext to obtain the 56-byte payload to be encrypted. From the 56-byte payload to be encrypted, bytes 1 to 16 are extracted in sequence as the first freshness factor on the decryption side, bytes 17 to 24 are used as the public key binding verification code on the decryption side, and bytes 25 to 56 are used as the current session key on the decryption side.

[0040] Specifically, generating the message authentication code that includes the first ciphertext and the second ciphertext containing the new session key also includes:

[0041] The second negotiation unit uses 32 bytes of the current session key on the decryption side as the key for HMAC-SHA256 operation and 16 bytes of the first freshness factor on the decryption side as the message for HMAC-SHA256 operation. It performs one HMAC-SHA256 operation to obtain a 32-byte operation result. The first 8 bytes of the 32-byte operation result are extracted as the verification code bound to the public key on the verification side. The 8 bytes of the verification code bound to the public key on the verification side are XORed with the 8 bytes of the verification code bound to the public key on the decryption side byte by byte. If the XOR result of any byte is not zero, the current session key on the decryption side obtained by decryption is determined to be invalid, the first ciphertext is discarded and the processing is terminated.

[0042] Specifically, generating the message authentication code that includes the first ciphertext and the second ciphertext containing the new session key also includes:

[0043] If the XOR result of all 8 bytes is zero, the second negotiation unit determines the current session key on the decryption side as the valid current session key, uses the 32 bytes of the valid current session key as the key for HMAC-SHA256 operation, and uses the byte string formed by concatenating all 289 bytes of the first ciphertext and all bytes of the second ciphertext containing the new session key in the order of the first ciphertext first and the second ciphertext last as the message for HMAC-SHA256 operation, performs one HMAC-SHA256 operation, and uses the 32-byte operation result as the message authentication code.

[0044] Based on the improved Diffie-Hellman dynamic key negotiation method, including:

[0045] When the four-way vehicle triggers a network switching event, the trust domain identifier of the target warehouse gateway is obtained and compared with the current trust domain identifier stored locally. If the trust domain identifiers match, a valid current session key is obtained, and the current session key and the generated first freshness factor are encrypted with the public key of the target warehouse gateway to construct a first ciphertext carrying a renegotiation flag and send it.

[0046] After receiving the first ciphertext and identifying the renegotiation marker, the system uses its own private key to decrypt and obtain the current session key and the first freshness factor. The system then uses the current session key as the key for the message authentication code to generate the first ciphertext and a message authentication code containing the new session key. Finally, the system sends a response message containing the message authentication code and the second ciphertext.

[0047] Upon receiving the response message, the validity of the message authentication code is verified based on the current session key. If valid, the second ciphertext is decrypted to obtain a new session key, which is then used to replace the current session key.

[0048] If the trust domain identifiers are inconsistent, the session key and key parameters associated with the current trust domain in the local security context are cleared, and a complete Diffie-Hellman key negotiation process based on the device fingerprint and the gateway public key is initiated.

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

[0050] This invention significantly reduces key negotiation overhead and service interruption latency during four-way vehicle cross-region handover by constructing a trust domain-aware adaptive dynamic key negotiation mechanism, while ensuring communication security. Specifically, when a network handover is triggered, the first negotiation unit first reliably obtains the trust domain identifier of the target warehouse gateway by performing multi-sampling statistics and signal strength weighted decision on the target warehouse gateway beacon frame and compares it with the currently stored trust domain identifier. If it is an intra-domain handover, a lightweight renegotiation process is initiated. Using the verified and valid current session key and a first freshness factor derived from the key identifier, negotiation sequence number, and trust domain identifier, the key is encrypted with the target warehouse gateway's public key and sent. The second negotiation unit performs public key fingerprint pre-verification, RSA decryption, and public key binding verification code. After double verification, the new session key is securely distributed using the current session key as the message authentication key. The entire lightweight process requires only a single round trip to complete the key migration, with the time consumption controlled in the millisecond range, ensuring that the transmission of scheduling instructions is not imperceptibly interrupted. In the case of cross-domain handover, it automatically falls back to the complete key negotiation process based on device fingerprint and elliptic curve Diffie-Hellman algorithm. By concatenating the device fingerprint digest and the shared secret and inputting them into the key derivation function, the generated session key is simultaneously bound to the device hardware characteristics and the temporary shared secret, realizing the cryptographic binding of the session key and the device identity. This mechanism achieves adaptive matching between negotiation strength and network change degree, avoiding unnecessary full asymmetric renegotiation computation overhead during intra-domain handover, and ensuring high-security authentication during cross-domain handover. It effectively overcomes the signaling storm and computational resource waste caused by full renegotiation triggered by handover in traditional schemes, and takes into account the efficiency and robustness of key negotiation in mobile warehousing scenarios. Attached Figure Description

[0051] Figure 1 This is a diagram of the dynamic key negotiation system based on the improved Diffie-Hellman method in Embodiment 1 of the present invention;

[0052] Figure 2 This is a flowchart illustrating the process of obtaining the trust domain identifier of the target warehouse gateway in Embodiment 2 of the present invention.

[0053] Figure 3This is a flowchart of the dynamic key negotiation method based on the improved Diffie-Hellman method in Embodiment 3 of the present invention. Detailed Implementation

[0054] Example 1

[0055] Please see Figure 1 The present invention provides an embodiment of an improved Diffie-Hellman dynamic key negotiation system, comprising: a first negotiation unit deployed on a four-way vehicle and a second negotiation unit deployed on a warehouse gateway;

[0056] The first negotiation unit is configured to, when the four-way vehicle triggers a network switching event, obtain the trust domain identifier of the target warehouse gateway and compare it with the current trust domain identifier stored locally; if the trust domain identifiers are consistent, obtain a valid current session key, encrypt the current session key and the generated first freshness factor with the public key of the target warehouse gateway, construct a first ciphertext carrying a renegotiation marker and send it.

[0057] The second negotiation unit is configured to receive the first ciphertext, identify the renegotiation marker, decrypt it using its own private key to obtain the current session key and the first freshness factor, use the current session key as the key for the message authentication code, generate the first ciphertext and the second ciphertext containing the new session key, and send a response message containing the message authentication code and the second ciphertext.

[0058] The first negotiation unit is also configured to receive the response message, verify the validity of the message authentication code based on the current session key, and if the verification is valid, the first negotiation unit decrypts the second ciphertext with the current session key to obtain a new session key, replaces the current session key in the local secure storage area with the new session key, resets the lightweight negotiation counter to 1, updates the key identifier to the new value corresponding to the new session key, and completes this intra-domain fast key migration.

[0059] If the verification fails, the first negotiation unit determines that the lightweight renegotiation has failed, discards the response message, marks the current session key in the local secure storage area as pending verification, and resends the first ciphertext to the target warehouse gateway up to a preset retry limit. If no valid response message is received after the retry limit is reached, the first negotiation unit determines that the current session key is unavailable on the target warehouse gateway side or the communication link has been attacked, clears the local security context, erases the current session key from the local secure storage area, terminates the lightweight renegotiation process, and initiates a fully improved Diffie-Hellman key negotiation process based on device fingerprints and gateway public keys to re-establish the session key required for secure communication. In this embodiment, the preset retry limit is specifically set as an integer constant and fixed in the local secure storage area or the non-volatile configuration register of the hardware security module during the initialization phase of the first negotiation unit of the four-way vehicle or when the security policy is loaded. This threshold is set to a positive integer of 3 to 5 times based on the packet loss rate of the warehouse network environment. The preset threshold, together with the renegotiation response timer started by the first negotiation unit after sending the first ciphertext, constitutes a timeout retransmission mechanism, wherein the timeout duration of the renegotiation response timer is set to 500 milliseconds. When the first negotiation unit determines that the lightweight renegotiation has failed due to invalid message authentication code verification or response timeout, it marks the current session key as pending verification and retransmits the first ciphertext to the target warehouse gateway in a loop, limited by the preset threshold. If a valid response message is received before reaching the preset retry limit, the new session key replacement is completed normally and the retry counter is reset; otherwise, if no valid response is received after reaching the preset limit, it is determined that the current session key is no longer available on the target gateway side or the communication link has been maliciously attacked, and then the local security context is cleared, the current session key is erased, and the process reverts to the complete improved Diffie-Hellman negotiation process based on device fingerprint and gateway public key, which effectively avoids signaling storms and unnecessary consumption of hardware security module computing resources caused by unlimited retries while ensuring the reliability of lightweight renegotiation.

[0060] In this embodiment, the lightweight renegotiation and retry process is as follows:

[0061] Before each retry to send the first ciphertext, the first negotiation unit must re-execute the complete first freshness factor generation process: perform an atomic increment operation on the lightweight negotiation counter to obtain the updated negotiation sequence number; reassemble the received derived byte string using the updated negotiation sequence number, the original key identifier, and the original trust domain identifier; re-execute the HMAC-SHA256 operation using the current session key to generate a new first freshness factor; synchronously recalculate the public key binding verification code, concatenate the new payload to be encrypted, and perform RSA encryption to generate a completely new first ciphertext before sending it. The negotiation sequence number for each retry is strictly monotonically increasing to ensure that the retransmitted first ciphertext possesses independent freshness.

[0062] The second negotiation unit maintains a record of the maximum received negotiation sequence number bound to each session key. If the received negotiation sequence number is less than or equal to the maximum recorded value, it is directly determined as a replay request and discarded.

[0063] The first negotiation unit is further configured to: if the trust domain identifiers are inconsistent, terminate the current lightweight renegotiation process, and after re-acquiring the trust domain identifier of the target warehouse gateway through a preset number of acquisition windows and determining that each acquisition is a cross-domain switch, clear the session key and key parameters associated with the current trust domain in the local security context, and initiate a fully improved Diffie-Hellman key negotiation process based on device fingerprints and gateway public keys, specifically:

[0064] The first negotiation unit collects the hardware serial number and operating system characteristics of the four-way vehicle to form the original value of the device fingerprint, performs a hash operation on the original value of the device fingerprint to obtain the device fingerprint digest; calls the hardware security module to generate a first temporary private key, calculates a first temporary public key based on the elliptic curve base point, and sends the first temporary public key and the device fingerprint digest to the second negotiation unit; in this embodiment, the preset number of times is the threshold for repeated judgment of the collection window. This threshold is preset in the form of an integer constant and solidified in the non-volatile configuration register of the hardware security module during the initialization or security policy loading stage of the first negotiation unit; according to the instantaneous misjudgment probability of beacon frames in the warehousing environment and the fault tolerance requirements of cross-domain handover confirmation, this threshold is set to a positive integer of 2 or 3. When the first acquisition window determines that the trust domain identifier is inconsistent, the first negotiation unit terminates the current lightweight renegotiation process and enters a silent interval. Then, it repeatedly executes a secondary confirmation process to reacquire the target warehouse gateway trust domain identifier, with the preset threshold as the upper limit. If any reacquisition before reaching the preset number of attempts is determined to be an intra-domain handover, it immediately switches to intra-domain lightweight renegotiation. If every reacquisition after reaching the preset upper limit is determined to be a cross-domain handover, the cross-domain handover is confirmed, the local security context is cleared, and a complete improved Diffie-Hellman negotiation process is initiated. This preset mechanism effectively filters out misjudgments of single ghost signals caused by multipath reflection or co-frequency crosstalk through a limited number of repeated sampling decisions, ensuring the accuracy of cross-domain handover decisions while avoiding uncontrollable handover delays caused by infinite waiting.

[0065] In this embodiment, the hardware serial number includes at least one of the CPU serial number, motherboard serial number, or storage module serial number, and the operating system features include the operating system version number and kernel compilation identifier. The first negotiation unit concatenates the above fields in a preset order with a preset separator to form the original value of the device fingerprint, and performs a hash operation on the original value of the device fingerprint using the SHA-256 algorithm to output a 256-bit device fingerprint digest. The first negotiation unit calls the true random number generator in the hardware security module to generate a 256-bit candidate random number, performs non-zero check and secp256r1 elliptic curve order check on the candidate random number in sequence, and determines the candidate random number that passes the check as the first temporary private key; performs a dot product operation between the first temporary private key and the base point of the elliptic curve to obtain the first temporary public key point, performs uncompressed dot encoding on the first temporary public key point, and outputs the first temporary public key. The first negotiation unit assembles the first temporary public key and the device fingerprint digest into a complete renegotiation request message and sends it. In this embodiment, the preset order is pre-written into the permanent storage area of ​​the hardware security module in the form of configuration parameters during the firmware burning stage or security policy loading and initialization process of the first negotiation unit. Specifically, the CPU serial number, motherboard serial number, storage module serial number, operating system version number, and kernel compilation identifier are fixedly arranged according to the principle of hardware identifier priority and uniqueness priority. This ensures that the first negotiation unit strictly follows the same splicing order every time it performs device fingerprint collection, thereby providing stable and reproducible input data for subsequent SHA-256 hash operations. This avoids differences in device fingerprint digests generated by the same four-way vehicle due to changes in field order, and ensures the uniqueness, consistency, and verifiability of the device fingerprint.

[0066] In this embodiment, the preset separator is predefined as a character constant in the device fingerprint security policy configuration file and embedded in the fingerprint generation module of the first negotiation unit. The selection principle is to use special characters not included in the original strings of each hardware serial number and operating system feature, such as the vertical bar character "|" or the underscore character "-", as explicit boundary markers between fields. When concatenating the original device fingerprint value, the first negotiation unit inserts the preset separator sequentially between the predetermined fields, so that adjacent fields form clear length boundaries on the byte sequence. This effectively avoids fingerprint ambiguity and hash collision risks caused by the natural connection of adjacent fields or variable field lengths, ensuring that the generated original device fingerprint value encoding structure is clear and consistent, and can be accurately restored and matched by the second negotiation unit in the subsequent complete Diffie-Hellman negotiation process according to the same rules.

[0067] The second negotiation unit matches and verifies the received device fingerprint digest with the registered device fingerprint database. After successful verification, it calls the hardware security module to generate a second temporary private key, calculates a second temporary public key based on the elliptic curve base point, and sends the second temporary public key to the first negotiation unit.

[0068] In this embodiment, an extended description of the first temporary public key verification logic is as follows:

[0069] After receiving the first temporary public key, the second negotiation unit first performs an elliptic curve point validity check: it parses the uncompressed public key point coordinates (x, y), verifies that x and y are both non-negative integers less than the curve order p of secp256r1, and satisfy the curve equation. Simultaneously, it verifies that the point is not at infinity; if the verification fails, the public key is deemed invalid, and the negotiation process is terminated. Here, x and y are the x and y coordinates of any point on the elliptic curve, respectively, and their values ​​are integers ranging from 0 to a large prime number p-1; a and b are pre-selected fixed coefficients that jointly determine the geometric shape of the curve and must satisfy constraints to ensure that the curve has no singularities; p is a large prime number, and all operations are performed on a finite field modulo p, meaning that the remainders of the values ​​on both sides of the equation divided by p are equal. The congruence symbol indicates that the equality relationship is modulo p. All operation results fall within the integer range of 0 to p-1. For example, when the intermediate result X = p+1, X mod p = 1, that is, X ≡1 (mod p). The valid result takes the remainder 1.

[0070] Freshness verification is implemented using a timestamp window: when the first negotiation unit sends the first temporary public key, it simultaneously attaches a local timestamp in big-endian format, in milliseconds; after receiving it, the second negotiation unit calculates the difference between this timestamp and the local gateway time. If the absolute value of the difference exceeds a preset 5-second time window, the request is deemed expired and discarded. This time window matches the maximum transmission latency of the warehouse network, effectively defending against replay attacks while ensuring tolerance for slight clock skew.

[0071] In this embodiment, the registered device fingerprint database is stored in the protected storage area of ​​the hardware security module where the second negotiation unit is located. Each record in the database contains a mapping relationship between the device identifier and the device fingerprint digest. The specific method of the matching verification is as follows: the 256 bits of the received device fingerprint digest are compared byte by byte with each registered device fingerprint digest stored in the registered device fingerprint database. If the XOR result of 32 pairs of bytes of a record is all zero, the verification is deemed successful, and the corresponding device identifier is recorded. If the comparison with all records is inconsistent, the verification is deemed unsuccessful, and the negotiation request is discarded. The second negotiation unit calls the true random number generator in the hardware security module to generate a second temporary private key. The generation process of the second temporary private key is the same as that of the first temporary private key, both of which must pass non-zero check and secp256r1 elliptic curve order check. The second negotiation unit performs a dot product operation between the second temporary private key and the base point of the elliptic curve to obtain a second temporary public key point, performs uncompressed dot encoding on the second temporary public key point to obtain the second temporary public key, and sends the second temporary public key to the first negotiation unit.

[0072] The first negotiation unit calculates a first shared secret based on the first temporary private key and the second temporary public key, and the second negotiation unit calculates a second shared secret based on the second temporary private key and the first temporary public key.

[0073] In this embodiment, the first negotiation unit uses the first temporary private key as a scalar and the elliptic curve point corresponding to the second temporary public key as the base point for the dot product. It performs an elliptic curve scalar dot product operation using the Montgomery step algorithm. After performing an infinity check on the result point, it extracts the 256-bit big-endian unsigned integer feature of the point's x-coordinate as the first shared secret. The second negotiation unit uses the second temporary private key as a scalar and the elliptic curve point corresponding to the first temporary public key as the base point for the dot product. It performs the same Montgomery step algorithm and uses the same curve parameters to perform an elliptic curve scalar dot product operation, extracting the 256-bit big-endian unsigned integer feature of the result point's x-coordinate as the second shared secret. The first shared secret and the second shared secret are numerically equal.

[0074] The first negotiation unit concatenates the first shared secret with the device fingerprint digest and inputs the result into a key derivation function to generate a new session key. The second negotiation unit concatenates the second shared secret with the verified device fingerprint digest and inputs the result into the key derivation function to generate the new session key.

[0075] In this embodiment, the specific method of concatenation is as follows: the 256 bits of the first shared secret are placed in the high-order bits, and the 256 bits of the device fingerprint digest are placed in the low-order bits, concatenating them bit by bit to form a 512-bit concatenation result; the second negotiation unit uses the same concatenation order, placing the 256 bits of the second shared secret in the high-order bits and the 256 bits of the verified device fingerprint digest in the low-order bits, concatenating them to form a 512-bit concatenation result. The key derivation function is the HKDF function based on HMAC-SHA256, using the 512-bit concatenation result as input key material, a preset shared salt value as the salt parameter, and the current job task identifier as the info context parameter, sequentially performing HMAC-SHA256 operations in the extraction and expansion phases, outputting the 256-bit new session key. The new session keys generated by the first negotiation unit and the second negotiation unit are numerically identical. In this embodiment, the preset shared salt value is a fixed-length byte string generated by the backend key management server using a true random number generator within the hardware security module during the initial deployment phase of the warehouse management system or when the four-way vehicle and the warehouse gateway complete their initial device registration. This string is simultaneously written to the non-volatile storage area of ​​the hardware security modules of the first and second negotiation units via secure offline distribution, serving as a fixed input parameter in the HKDF extension stage of the key derivation function. This shared salt value remains consistent across all warehouse gateways and registered four-way vehicles within the trust domain and remains statically unchanged throughout the system's entire lifecycle. Its specific value is preset in the security policy configuration file in hexadecimal constant form. When executing the complete improved Diffie-Hellman negotiation process, both the first and second negotiation units read this preset shared salt value from their local secure storage area and use it as the salt parameter in the HKDF extraction stage to participate in the derivation operation of the new session key. This ensures that both parties, based on the input key material formed by concatenating the shared secret and the device fingerprint digest, output a consistent 256-bit new session key after function mapping with the same salt value, thereby establishing a common basis for session key generation in the complete negotiation process.

[0076] In this embodiment, the specific process of the HKDF key derivation operation is as follows:

[0077] Using a 32-byte shared salt value as the HMAC-SHA256 key and a 64-byte concatenated 512-bit result as the HMAC-SHA256 message, perform one HMAC-SHA256 operation and output a 32-byte pseudo-random key PRK.

[0078] Using the extracted PRK as the HMAC-SHA256 key, the 16 bytes of the current job task identifier and the single-byte constant 0x01 are concatenated in the order of task identifier first, constant last, to form a message. One HMAC-SHA256 operation is then performed, yielding a 32-byte output. Since the target output length of 256 bits is equal to the output length of a single HMAC-SHA256 operation, multiple iterations are unnecessary; this 32-byte output is directly used as the final derived 256-bit new session key. The current job task identifier is a unique 16-byte task number issued by the warehouse management system to the four-way vehicle, stored in big-endian byte order in the four-way vehicle's local task register.

[0079] As a concrete example, a large e-commerce warehousing center deploys eighty 4x4 AGVs, divided into eight warehousing areas, A1 to A8. Each area has one warehousing gateway, and all eight gateways belong to the same trust domain. The trust domain identifier is a 4-byte hexadecimal value, 0x4C4F4749. AGV-07 is currently performing a cargo handling task in area A3. Its first negotiation unit has used the session key generated during this operation with the A3 area warehousing gateway through a fully improved Diffie-Hellman key negotiation process as the current session key. The session key structure in the local secure storage area stores: the 32-byte value of the current session key, the key identifier 0xA3F29E7B1C084D56, the current value of the lightweight negotiation counter (2), the current trust domain identifier 0x4C4F4749, and the target warehousing gateway's public key and its public key fingerprint value, which are mapped to the trust domain identifier 0x4C4F4749.

[0080] During the high-speed travel of AGV-07 along the tunnel, the first negotiation unit reads the signal strength value of the current access link from the received signal strength indicator register of the wireless communication module with a sampling period of 100 milliseconds. The signal strength value continuously decreases from -45dBm. When the signal strength value drops to -78dBm and the duration of the value being lower than the preset threshold value of -75dBm reaches the preset duration of 300 milliseconds, the first negotiation unit determines that a network switching event has been triggered and immediately starts a collection window with a preset collection duration of 200 milliseconds. Within the acquisition window, the first negotiation unit sequentially receives five beacon frames broadcast by the A5 area warehouse gateway. It extracts the candidate trust domain identifier field from the extended area information element of each beacon frame, obtaining five candidate trust domain identifier values: 0x4C4F4749, 0x4C4F4749, 0x4C4F4749, 0x4C4F4748, and 0x4C4F4749, corresponding to received signal strength indication values ​​of -68dBm, -65dBm, -70dBm, -82dBm, and -67dBm, respectively. The first negotiation unit performs deduplication on these five candidate trust domain identifiers, obtaining two different candidate trust domain identifiers: 0x4C4F4749 and 0x4C4F4748. According to statistics, 0x4C4F4749 appears 4 times, and the ratio of its occurrence count to the total number of beacon frame records (5) is 0.8, exceeding the preset ratio threshold of 0.6. Furthermore, the arithmetic mean of all its corresponding received signal strength indicators is -67.5 dBm. 0x4C4F4748 appears 1 time, and the ratio of its occurrence count to the total number of beacon frame records (5) is 0.2, which does not exceed the preset ratio threshold of 0.6. Its average signal strength value is -82 dBm. The first negotiation unit determines 0x4C4F4749, the candidate trust domain identifier that meets the occurrence count ratio condition and has the largest average signal strength value, as the trust domain identifier of the target warehouse gateway. The first negotiation unit performs a byte-by-byte XOR operation between the 4-byte value of this trust domain identifier and the current trust domain identifier 0x4C4F4749 stored in the local secure storage area, in byte-by-byte order (1st to 4th byte). Since all four pairs of bytes XORed result in zero, the comparison result is consistent, and it is determined that this network handover is an intra-domain handover.

[0081] The first negotiation unit then initiates a lightweight renegotiation process. It reads the key identifier 0xA3F29E7B1C084D56 from the session key structure in the local secure storage area, reads the current value of the lightweight negotiation counter (2), and performs an atomic increment operation on the lightweight negotiation counter to obtain the negotiation sequence number 3 for this negotiation. The first negotiation unit concatenates the 8 bytes of the key identifier, the 4 bytes of the negotiation sequence number 3 (big-endian unsigned integer characteristic), and the 4 bytes of the trust domain identifier 0x4C4F4749 in the order of key identifier first, negotiation sequence number in the middle, and trust domain identifier last to form a 16-byte derivation string. Using the 32 bytes of the current session key as the key for HMAC-SHA256 operation, and the 16-byte derivation string as the message for HMAC-SHA256 operation, the HMAC-SHA256 operation is performed to obtain a 32-byte output value. The first 16 bytes of this output value are taken as the first freshness factor. The first negotiation unit reads the target warehouse gateway public key and its public key fingerprint value mapped to the gateway public key mapping table in the local secure storage area, using the trust domain identifier 0x4C4F4749 as the index. It uses the 32 bytes of the current session key as the key for the HMAC-SHA256 operation and the 16 bytes of the first freshness factor as the message for the HMAC-SHA256 operation, performing the HMAC-SHA256 operation to obtain a 32-byte output value. The first 8 bytes of this output value are used as the public key binding verification code. The first negotiation unit concatenates the 16 bytes of the first freshness factor, the 8 bytes of the public key binding verification code, and the 32 bytes of the current session key in the following order: first freshness factor first, public key binding verification code in the middle, and current session key last, to form a 56-byte payload to be encrypted. Using the target warehouse gateway public key as the encryption key, and employing RSAES-OAEP with the SHA-256 hash algorithm as the padding scheme, it performs an RSA-2048 encryption operation on the 56-byte payload to be encrypted, obtaining a 256-byte payload ciphertext. The first negotiation unit places 32 bytes of the public key fingerprint value in bytes 1 to 32, 256 bytes of the payload ciphertext in bytes 33 to 288, and the renegotiation flag 0x01 in byte 289, concatenating them to form a 289-byte first ciphertext, which is then sent to the A5 area warehouse gateway via the wireless communication module.

[0082] After receiving the first ciphertext, the second negotiation unit of the A5 regional warehouse gateway reads the value of byte 289 of the first ciphertext as 0x01. This value is compared with the preset renegotiation type constant value of 0x01, and the result is equal, confirming a lightweight renegotiation request. The second negotiation unit reads bytes 1 to 32 of the first ciphertext as the receiving side's public key fingerprint value, reads its own public key fingerprint value stored in the local secure storage area, and performs a byte-by-byte XOR operation between the 32 bytes of the receiving side's public key fingerprint value and the 32 bytes of its own public key fingerprint value. If the XOR result of all 32 pairs of bytes is zero, the public key fingerprint value is determined to match. The second negotiation unit reads bytes 33 to 288 of the first ciphertext as the payload ciphertext, uses its own stored RSA-2048 private key as the decryption key, and uses SHA-256 as the OAEP hash function to perform RSAES-OAEP decryption operation on the 256-byte payload ciphertext to obtain a 56-byte payload to be encrypted. From bytes 1 to 16 of the payload to be encrypted, it extracts the first freshness factor on the decryption side, bytes 17 to 24 extract the public key binding verification code on the decryption side, and bytes 25 to 56 extract the current session key on the decryption side. The second negotiation unit uses 32 bytes of the current session key on the decryption side as the key for HMAC-SHA256 operation and 16 bytes of the first freshness factor on the decryption side as the message for HMAC-SHA256 operation. It performs one HMAC-SHA256 operation, takes the first 8 bytes of the operation result as the verification code bound to the public key on the verification side, and performs an XOR operation byte by byte between the 8 bytes of the verification code bound to the public key on the verification side and the 8 bytes of the verification code bound to the public key on the decryption side. If the XOR result of all 8 pairs of bytes is zero, it is determined that the current session key on the decryption side obtained by decryption is valid. The second negotiation unit determines the current session key on the decryption side as the valid current session key, uses 32 bytes of this valid current session key as the key for HMAC-SHA256 operation, and uses the entire 289 bytes of the first ciphertext and the entire bytes of the second ciphertext containing the new session key, concatenated in the order of first ciphertext first and second ciphertext last, to form the byte string for HMAC-SHA256 operation. The unit performs one HMAC-SHA256 operation, uses the resulting 32 bytes as the message authentication code, and assembles the message authentication code and the second ciphertext into a response message and sends it to AGV-07.

[0083] After receiving the response message, the first negotiation unit of AGV-07 recalculates the message authentication code using the current session key and compares it with the message authentication code in the response message. If the comparison matches, the message authentication code is deemed valid. The first negotiation unit decrypts the second ciphertext using the current session key to obtain the new session key. It then replaces the current session key field in the session key structure in the local secure storage area with the new session key. The lightweight negotiation counter is reset to 1, and the key identifier is updated to the new value corresponding to the new session key, completing this intra-domain fast key migration. The entire lightweight renegotiation process, from the sending of the first ciphertext to the receipt of the response message, takes only 15 milliseconds. During this period, the transmission of scheduling instructions for AGV-07 is not subject to any perceptible interruption, and the handling task instructions issued by the warehouse management system continue to be executed normally.

[0084] Example 2

[0085] Please see Figure 2 It should be further explained that, in this embodiment, when the four-way vehicle triggers a network switching event, the trust domain identifier of the target warehouse gateway is obtained, including:

[0086] A101. When the first negotiation unit detects that the signal strength value of the current access link is continuously lower than a preset threshold value and the duration reaches a preset duration, it determines that a network handover event is triggered and starts a collection window with a duration of a preset collection duration; if the signal strength value is not continuously lower than the preset threshold value or the duration does not reach the preset duration, the first negotiation unit determines that a network handover event has not been triggered, resets the continuous weak signal counter to zero, and continues to monitor the signal strength value of the current access link at a preset sampling period.

[0087] In this embodiment, the first negotiation unit reads the signal strength value of the current access link from the received signal strength indicator register of the four-way vehicle wireless communication module with a sampling period of 100 milliseconds. The signal strength value is represented by an 8-bit signed integer. The first negotiation unit performs a signed integer comparison operation between each read signal strength value and the preset threshold value. If the signal strength value is less than the preset threshold value, the sampling is marked as a weak signal sampling point. The preset threshold value is set to -75dBm because: in a warehouse wireless communication environment, reliable communication between the four-way vehicle and the warehouse gateway requires a signal strength value of no less than -72dBm. When the signal strength value decays to -75dBm, the receiving sensitivity is close to the minimum demodulation threshold of the communication module. Continuing to maintain the current connection will cause the bit error rate to rise sharply to more than one in a thousand, and the urgency of triggering a handover is clearly established. If the threshold value is set too high, the four-way vehicle will initiate a handover when the signal strength can still support reliable communication, resulting in an unnecessary increase in the frequency of handovers. If the threshold value is set too low, the communication link will be severely degraded when the handover is initiated, resulting in an excessively high packet loss rate for signaling interaction during the handover process. The preset duration is set to 300 milliseconds because: when the four-way vehicle travels at high speed through the rack aisle, the metal racks can cause brief signal dips, with each dip typically lasting between 100 and 200 milliseconds. If the preset duration is less than 200 milliseconds, these occasional momentary signal dips may be mistaken for network handover events, triggering unnecessary key negotiation procedures. If the preset duration exceeds 500 milliseconds, the four-way vehicle will delay handover even when the signal has already attenuated, resulting in the loss of scheduling instructions before the handover begins. The first negotiation unit maintains a continuous weak signal counter, initially set to zero. When a weak signal sampling point is detected, the counter is incremented by 1; when a non-weak signal sampling point is detected, the counter is reset to zero. When the product of the current value of the continuous weak signal counter and the sampling period reaches the preset duration of 300 milliseconds (i.e., when the continuous weak signal counter accumulates to 3), the first negotiation unit determines that the network handover event has been triggered. Upon determining that the network switching event has been triggered, the first negotiation unit immediately initiates the acquisition window and starts a hardware timer with a duration equal to the preset acquisition duration. The preset acquisition duration is set to 200 milliseconds because: the beacon frame broadcast period of the target warehouse gateway is typically 100 milliseconds; a 200-millisecond acquisition window ensures that at least two complete beacon frame periods are received; and the sum of the 200-millisecond acquisition window and the 300-millisecond signal attenuation determination duration is 500 milliseconds. This total duration still provides sufficient time for lightweight renegotiation execution during the process of the four-way vehicle passing through the coverage area of ​​a single access point at maximum speed.

[0088] A102. Within the acquisition window, the first negotiation unit sequentially receives N beacon frames broadcast by the target warehouse gateway, where N is an integer greater than or equal to 3. It extracts the candidate trust domain identifier field from the extended area information element of each beacon frame and records the received signal strength indication value corresponding to the beacon frame, thereby obtaining a one-to-one correspondence between the N candidate trust domain identifiers and the N received signal strength indication values.

[0089] In this embodiment, during the period before the hardware timer reaches the preset acquisition duration of 200 milliseconds, the first negotiation unit continuously monitors the wireless channel and receives beacon frames broadcast by the target warehouse gateway. The first negotiation unit reads the 37th byte to the terminal's vendor-defined information element field from the frame body of each received beacon frame, parses the element identifier of this field, and if the value of the element identifier is equal to the preset vendor-private identifier value 0xDD, then the information element is determined as the extended area information element. The first negotiation unit extracts the candidate trust domain identifier field from the 1st to 4th bytes of the content field of the extended area information element. The candidate trust domain identifier field is a big-endian representation of a 4-byte unsigned integer. The first negotiation unit reads the received signal strength indicator value corresponding to the beacon frame from the received signal strength indicator register of the wireless communication module. The received signal strength indicator value is represented as an 8-bit signed integer. The first negotiation unit appends the 4-byte value of the candidate trust domain identifier field and the 1-byte value of the received signal strength indicator to a preset acquisition buffer in the order of reception. When the hardware timer reaches the preset acquisition duration of 200 milliseconds, the acquisition window is closed. The first negotiation unit counts the total number of beacon frame records stored in the acquisition buffer and assigns the total number to N. If N is less than 3, the first negotiation unit determines that the number of beacon frames received in the current acquisition window is insufficient, discards all data in the acquisition buffer, and restarts the acquisition window after a preset silence interval of 100 milliseconds. The reason for setting the lower limit of N to 3 is as follows: within the preset acquisition time of 200 milliseconds, if the beacon frame broadcast period of the target warehouse gateway is 100 milliseconds, theoretically two beacon frames can be received. However, due to the random phase offset between the beacon frame transmission time and the start time of the acquisition window, and the multipath effect in the warehouse environment, some beacon frames may be lost due to collisions or deep fading. The actual number of beacon frames that can be reliably received fluctuates. Setting the lower limit of N to 3 can ensure that the subsequent frequency statistics and average signal strength value calculation are based on no less than 3 samples, avoiding misjudgment of the trust domain identifier due to the accidental reception of cross-regional ghost signals in one or two instances.

[0090] In this embodiment, the vendor-defined information element of the 802.11 beacon frame follows the standard TLV format. The first byte is the element identifier (EID), with a fixed value of 0xDD indicating a vendor-private element; the second byte is the length field (Len), which is an unsigned integer representing the number of bytes in the subsequent content field; the third byte onwards is the content field. During the first negotiation unit's parsing, it first checks whether the value of the length field is ≥4. If it is less than 4, the content field is less than 4 bytes and cannot carry the complete candidate trust domain identifier, so the information element is directly discarded. If the check passes, it reads 4 bytes consecutively from the beginning of the content field (i.e., the 3rd byte of the entire information element), and parses these 4 bytes into a 32-bit unsigned integer in big-endian byte order as the candidate trust domain identifier. The 5th byte and beyond of the content field are reserved extension areas, which are ignored during parsing, and only the first 4 bytes are used for identifier extraction. For example, suppose we receive a hexadecimal sequence of a vendor-defined information element as DD 08 4C4F 47 49 01 02 03 04. Then 0xDD is the EID, 0x08 indicates that the content field is 8 bytes long, and the content field starts from 0x4C. The first 4 bytes 4C 4F 47 49 are decoded in big-endian order to obtain the trust field identifier 0x4C4F4749. The following 01 02 03 04 are ignored as reserved fields.

[0091] A103. Perform deduplication on the N candidate trust domain identifiers to obtain M different candidate trust domain identifiers, where M is a positive integer less than or equal to N;

[0092] In this embodiment, the first negotiation unit constructs a two-dimensional array in memory as a deduplication table. Each row of the deduplication table stores a 4-byte value of a different candidate trust domain identifier and the starting address of the corresponding received signal strength indication value list. The number of rows in the deduplication table is initially zero. The first negotiation unit sequentially reads each beacon frame record stored in the acquisition buffer according to the order of reception. For the 4-byte value of the candidate trust domain identifier in each record, it performs a byte-by-byte XOR operation with the 4-byte value of the candidate trust domain identifier in each row already stored in the deduplication table. If the XOR result with all 4 pairs of bytes in any row of the deduplication table is zero, it is determined that the candidate trust domain identifier already exists in the deduplication table, and the received signal strength indicator value in that record is appended to the received signal strength indicator value list corresponding to that row. If the XOR result with at least one pair of bytes in all stored rows of the deduplication table is not zero, it is determined that the candidate trust domain identifier does not appear in the deduplication table, a new row is added to the deduplication table, the 4-byte value of the candidate trust domain identifier is written into the new row, and the received signal strength indicator value in that record is used as the first element of the received signal strength indicator value list corresponding to the new row. After all N beacon frame records in the acquisition buffer have been processed, the first negotiation unit counts the total number of rows in the deduplication table and assigns the total number of rows to M.

[0093] A104. For each different candidate trust domain identifier, count the number of times it appears in the N candidate trust domain identifiers, and take the arithmetic mean of all the received signal strength indication values ​​corresponding to the candidate trust domain identifier to obtain the average signal strength value corresponding to the candidate trust domain identifier.

[0094] In this embodiment, the first negotiation unit traverses rows 1 to M of the deduplication table, and performs the following operations for each row: obtains the number of elements in the received signal strength indication value list corresponding to that row, and determines the number of occurrences of the candidate trust domain identifier corresponding to that row; accumulates the values ​​of all elements in the received signal strength indication value list as signed integers to obtain a sum, divides the sum by the number of occurrences, and rounds to zero using integer division to obtain the average signal strength value corresponding to the candidate trust domain identifier. The average signal strength value is represented by an 8-bit signed integer. The unit of the received signal strength indication value is dBm. The arithmetic mean operation is numerically equivalent to taking the geometric mean of the linear power values ​​of each signal strength value and then converting it back to dBm. In a warehouse aisle environment where the fluctuation range of the received signal strength indication value does not exceed 15dB, the deviation between the arithmetic mean and the geometric mean is less than 0.5dB, which is within the acceptable error range for engineering. Furthermore, the integer operation overhead of the arithmetic mean is much lower than that of the logarithmic field operation, adapting to the computing power constraints of the four-way vehicle embedded processor.

[0095] A105. The candidate trust domain identifier whose ratio of occurrence to N exceeds a preset ratio threshold and whose average signal strength value is the largest is determined as the trust domain identifier of the target warehouse gateway. The trust domain identifier is compared byte by byte with the current trust domain identifier stored in the local security storage area.

[0096] In this embodiment, the first negotiation unit traverses rows 1 to M of the deduplication table, calculates the floating-point quotient of the occurrence count divided by N for each row, and performs a floating-point comparison operation between the floating-point quotient and the preset proportion threshold. The preset proportion threshold is set to 0.6 because: if the occurrence count of a certain candidate trust domain identifier exceeds 0.6 in N beacon frames received within the acquisition window, it indicates that the candidate trust domain identifier is received more than half the time within the acquisition window, and has statistically significant dominance. The occurrence count of occasional ghost signals caused by multipath effects or co-channel crosstalk is usually less than 0.3. The proportion threshold of 0.6 provides sufficient discrimination margin between the proportion of legitimate signals and the proportion of interference signals. If the proportion threshold is set too low, occasional interference signals may meet the conditions due to fluctuations in instantaneous signal strength. If it is set too high, legitimate signals may not reach the proportion threshold when individual beacon frames are lost. The first negotiation unit determines all candidate trust domain identifiers that satisfy the floating-point quotient value greater than 0.6 as a candidate set. Within this candidate set, the average signal strength values ​​are sorted using a signed integer comparison operation, and the candidate trust domain identifier with the largest average signal strength value is determined as the trust domain identifier of the target warehouse gateway. If two or more candidate trust domain identifiers satisfy a preset ratio threshold, the one with the largest average signal strength value is selected as the trust domain identifier. This is because the average signal strength value directly reflects the physical distance and link quality between the four-way vehicle and each candidate gateway, and the gateway corresponding to the largest signal strength value is the optimal access gateway for the four-way vehicle's current location. The first negotiation unit performs an XOR operation byte-by-byte on the 4-byte value of the trust domain identifier and the 4-byte value of the current trust domain identifier stored in the local secure storage area, from byte 1 to byte 4. If the XOR result of all four pairs of bytes is zero, the comparison result is considered consistent; if the XOR result of any byte is not zero, the comparison result is considered inconsistent. The local secure storage area is a non-volatile storage area within the four-way vehicle hardware security module. The current trust domain identifier is issued by the second negotiation unit of the current warehouse gateway and written into the local secure storage area when the four-way vehicle first completes the full Diffie-Hellman key negotiation process with the current warehouse gateway.

[0097] In this embodiment, to adapt to the constraint that the four-way vehicle embedded processor has no hardware floating-point unit, the ratio determination uses integer multiplication instead of floating-point division: the number of occurrences of the candidate trust domain identifier is multiplied by 100 to obtain the integer numerator, and the total number of beacon frames N is multiplied by 60 to obtain the integer denominator threshold, corresponding to a preset ratio threshold of 0.6; the integer numerator is directly compared to see if it is greater than the integer denominator threshold, and if so, the ratio condition is determined to be met. This integer comparison method can be completed in a single cycle, and the operation time is only one-tenth of that of floating-point operation, with no loss of precision, perfectly matching the computing power constraints of the embedded environment.

[0098] A106. If the comparison results are consistent, it is determined that this network handover is an intra-domain handover, and the step of obtaining a valid current session key is executed.

[0099] In this embodiment, intra-domain switching means that the four-way vehicle switches from the coverage area of ​​the current warehouse gateway to the coverage area of ​​the target warehouse gateway. However, the current warehouse gateway and the target warehouse gateway belong to the same trust domain, and they share the same key management policy and registered device fingerprint database. The 4-byte value of the trust domain identifier is uniformly allocated to all warehouse gateways within the same trust domain by the key management server during the warehouse management system deployment initialization phase. Under intra-domain switching conditions, the current session key negotiated between the four-way vehicle and the current warehouse gateway is still a secure and valid key material in a cryptographic sense. The target warehouse gateway can verify the legitimacy of the current session key through the secure channel between it and the current warehouse gateway or through the key parameters associated in the local registered device fingerprint database. Therefore, intra-domain switching has the security premise of performing lightweight renegotiation to reuse the current session key. The first negotiation unit then reads the session key structure corresponding to the current session key from the local secure storage area. The session key structure includes a 32-byte value of the session key, a 1-byte value of the session key status register, an 8-byte value of the key identifier, and a 4-byte value of the lightweight negotiation counter. The first negotiation unit reads the value of the session key status register and determines whether it is equal to the valid status constant value 0x01. If it is equal, the 32-byte value of the current session key is loaded into the session key register of the hardware security module, and the subsequent process of lightweight renegotiation is entered. If it is not equal, it is determined that the current session key has expired, the local security context is cleared, and the complete Diffie-Hellman key negotiation process is initiated.

[0100] A107. If the comparison results are inconsistent, it is determined that this network switch is a cross-domain switch, the current switch process is terminated and the process waits for the next acquisition window to reacquire the trusted domain identifier.

[0101] In this embodiment, cross-domain handover means that the four-way vehicle moves from the coverage area of ​​the current warehouse gateway to the coverage area of ​​a target warehouse gateway belonging to a different trust domain. The different trust domains do not share a key management strategy, and the target warehouse gateway's registered device fingerprint database does not contain the key parameters associated with the four-way vehicle within the current trust domain. Therefore, the target warehouse gateway cannot verify the legitimacy of the session key negotiated by the four-way vehicle within the current trust domain. If a lightweight renegotiation is forcibly initiated under cross-domain handover conditions, the target warehouse gateway will reject the renegotiation request because it cannot associate the current session key, causing the four-way vehicle to waste handover window time in invalid signaling interactions and response timeouts. The specific operations of the first negotiation unit to terminate the current handover process include: clearing all data in the acquisition buffer, releasing the memory space occupied by the deduplication table, and resetting the continuous weak signal counter to zero. After terminating the current handover process, the first negotiation unit starts a silent timer with a preset silent interval of 100 milliseconds. During the silent timer's countdown, the first negotiation unit does not respond to any beacon frame reception events. After the silent timer expires, the first negotiation unit re-executes the determination process of detecting that the signal strength value of the current access link is continuously lower than a preset threshold value for a preset duration. The current handover process is terminated, and the unit waits for the next acquisition window to reacquire the trust domain identifier, instead of immediately initiating a complete Diffie-Hellman key negotiation process. This is because the discrepancy between the trust domain identifier determined in the current acquisition window and the current trust domain identifier may be a misjudgment caused by a brief reception of a cross-regional ghost signal or signal reflection within the acquisition window. By waiting for a second confirmation in the next acquisition window, occasional misjudgments in a single acquisition window can be effectively filtered out, avoiding the erroneous initiation of a complete cross-domain renegotiation when the four-way vehicle is still actually within the coverage area of ​​the original trust domain.In this embodiment, the preset silence interval is predefined as an integer constant in the security policy configuration file of the first negotiation unit and fixed in the non-volatile storage area of ​​the hardware security module, specifically set to 100 milliseconds. This setting is based on the fact that the beacon frame broadcast period of the target warehouse gateway is typically 100 milliseconds. After terminating the current lightweight renegotiation process, the first negotiation unit starts a silence timer with a duration of this preset silence interval. During the silence timer's countdown, the first negotiation unit does not respond to any beacon frame reception events, ensuring that the silence interval covers at least one complete beacon frame broadcast period, thus enabling the first negotiation unit to... After the silent period ends, the negotiation unit can start the next acquisition window with the synchronized phase to re-receive the beacon frames of the target warehouse gateway, avoiding the loss of beacon frame reception or insufficient samples in the acquisition window due to phase misalignment with the gateway broadcast cycle. The preset silent interval is written into the configuration register in a static configuration manner and remains constant throughout the entire system life cycle. This ensures that the first negotiation unit enters the waiting state with the same silent duration after each termination of lightweight renegotiation due to inconsistent trust domain identifiers. This effectively filters out occasional misjudgments in a single acquisition window while maintaining the periodicity, stability, and predictability of the switching process.

[0102] This process effectively overcomes the unreliable identification collection problem caused by multipath effects of wireless signals, co-frequency crosstalk, and instantaneous fluctuations in the warehouse environment by performing multi-beacon frame statistical judgment and fault tolerance verification on the trust domain identifier of the target warehouse gateway when the four-way vehicle triggers a network switching event. Specifically, the first negotiation unit does not rely on the instantaneous reception result of a single beacon frame. Instead, it uses the continuous attenuation of signal strength to a preset threshold and a preset duration as the handover trigger condition. By combining the preset threshold of -75dBm with a duration of 300 milliseconds, it effectively distinguishes between the 100-200 millisecond instantaneous signal dip caused by metal shelf obstruction and the actual signal attenuation, avoiding unnecessary key negotiation overhead caused by accidental handover triggered by occasional dips. Within the acquisition window, for candidate trust domain identifiers of multiple beacon frames, the first negotiation unit first counts the number of occurrences of each candidate trust domain identifier in N beacon frames, calculates its ratio to the total number of frames N, and includes candidate trust domain identifiers with a ratio exceeding a preset ratio threshold of 0.6 into the candidate set. Then, for each candidate trust domain identifier in the candidate set that meets this ratio condition, it calculates the arithmetic mean of all corresponding received signal strength indicators, and uses signed integer comparison operations to compare each candidate trust domain identifier in the candidate set. The average signal strength values ​​of the selected identifiers are sorted, and the candidate trust domain identifier with the largest average signal strength value is taken as the trust domain identifier of the target warehouse gateway. This achieves a dual determination based on frequency of occurrence as the primary condition and average signal strength as the selection criterion. This allows ghost identifiers that occasionally appear due to multipath reflection or cross-regional crosstalk to be automatically filtered out due to their low frequency of occurrence or weak signal strength, ensuring that the finally determined trust domain identifier truly reflects the optimal access gateway for the four-way vehicle's current location. At the same time, when the trust domain identifier is determined to be inconsistent with the current identifier, the high-overhead full Diffie-Hellman renegotiation is not immediately initiated. Instead, it waits for the next acquisition window for secondary confirmation, effectively filtering out occasional misjudgments in a single acquisition window. This avoids the four-way vehicle from erroneously triggering a full cross-domain renegotiation due to instantaneous ghost signals while still within the coverage area of ​​the original trust domain. Thus, while ensuring the accuracy of the handover decision, it significantly reduces the unnecessary consumption of computing resources and the latency of business communication interruption caused by identifier misjudgment.

[0103] It should be further explained that the generation process of the first freshness factor in this embodiment includes:

[0104] B101. The first negotiation unit reads the key identifier corresponding to the current session key stored in the local secure storage area. The key identifier is an 8-byte random number generated by the second negotiation unit and sent back to the first negotiation unit through the response message during the complete Diffie-Hellman key negotiation process.

[0105] In this embodiment, the key identifier is generated as follows: During the complete Diffie-Hellman key negotiation process, the second negotiation unit, while generating a new session key, calls the true random number generator within its hardware security module to generate an 8-byte random number as the key identifier. This key identifier is then assembled with the new session key and sent in the response message. After receiving the response message, the first negotiation unit associates the key identifier with the new session key and stores it in a session key structure in its local secure storage area. This session key structure includes a 32-byte session key value field, an 8-byte key identifier field, a 1-byte session key status register, and a 4-byte lightweight negotiation counter. The first negotiation unit reads the 8-byte value of the key identifier from the key identifier field. The reason for setting the key identifier to 8 bytes is that 8 bytes correspond to a 64-bit random number space. Among all the session keys generated during the entire life cycle of a single four-way vehicle, the probability of two different session keys generating the same key identifier is on the order of 2 to the power of negative 64. This can uniquely identify the session key generated by a single session key negotiation. Furthermore, the 8 bytes, together with the 4 bytes of the negotiation sequence number and the 4 bytes of the trust field identifier in the subsequent byte string to be derived, total 16 bytes, which is aligned with one-quarter of the 512-bit single compressed block length of HMAC-SHA256 operation.

[0106] B102. The first negotiation unit reads the lightweight negotiation counter that is locally maintained and bound to the current session key, performs an atomic increment operation on the lightweight negotiation counter, and determines the incremented count value as the negotiation sequence number of this negotiation.

[0107] In this embodiment, the lightweight negotiation counter is a 32-bit unsigned integer stored in the session key structure, and its initial value is set to zero when the current session key is first generated. The specific execution method of the atomic increment operation is as follows: the first negotiation unit sends an atomic addition instruction to the hardware security module. This instruction carries the byte offset address of the lightweight negotiation counter in the session key structure and the increment value of 1. After receiving the instruction, the hardware security module locks the bus area where the byte offset address is located, performs three steps—read, increment, and write back—and then releases the bus lock. During the locking period, the hardware security module refuses to respond to read / write requests from other bus master devices to that address. The negotiation sequence number identifies the number of times the current session key has been used before this lightweight renegotiation. After receiving the negotiation sequence number, the target warehouse gateway can compare it with the previously recorded negotiation sequence number corresponding to the session key. If the current negotiation sequence number is greater than the previously recorded negotiation sequence number, the current request is determined to be a new request; if the current negotiation sequence number is less than or equal to the previously recorded negotiation sequence number, the current request is determined to be a replay request and rejected.

[0108] B103. The first negotiation unit concatenates the 8 bytes of the key identifier, the 4 bytes of the negotiation sequence number (big-endian unsigned integer feature), and the trust domain identifier in the order of key identifier first, negotiation sequence number in the middle, and trust domain identifier last to form a byte string to be derived. The 32 bytes of the current session key are used as the key for HMAC-SHA256 operation, and the byte string to be derived is used as the message for HMAC-SHA256 operation. The HMAC-SHA256 operation is performed to obtain a 32-byte output value, and the first 16 bytes of the 32-byte output value are taken as the first freshness factor.

[0109] In this embodiment, the 4-byte big-endian unsigned integer characteristic of the negotiation sequence number is converted as follows: the 32-bit value of the negotiation sequence number is stored sequentially into bytes 1 to 4 in order from the most significant byte to the least significant byte. The trust domain identifier adopts the 4-byte value of the trust domain identifier of the target warehouse gateway. The total length of the byte string to be derived is 16 bytes, which is formed by tightly concatenating the 8 bytes of the key identifier, the 4 bytes of the negotiation sequence number, and the 4 bytes of the trust domain identifier in the aforementioned order, without inserting any delimiters or padding bytes after concatenation. The HMAC-SHA256 operation performs the following operations in sequence: If the 32-byte length of the current session key is greater than the SHA-256 block length of 64 bytes, then the SHA-256 hash operation is first performed on the current session key to obtain a 32-byte result as the actual key used. Since the current session key is exactly 32 bytes long, the 32 bytes of the current session key are directly used as the actual key used. The actual key used is XORed byte-by-byte with the iPad constant 0x36 and concatenated with the byte string to be derived, and the SHA-256 hash operation is performed to obtain the first intermediate value. The actual key used is XORed byte-by-byte with the iPad constant 0x5C and concatenated with the first intermediate value, and the SHA-256 hash operation is performed to obtain the 32-byte output value. The first negotiation unit takes the 1st to 16th bytes of the 32-byte output value as the first freshness factor. The security strength of 16 bytes is 128 bits, which is sufficient to resist exhaustive search attacks.

[0110] This process effectively solves the technical challenge of simultaneously satisfying unpredictability and bi-party synchronous verification in lightweight renegotiation processes by cryptographically binding the generation of the first freshness factor with the current session key, key identifier, negotiation sequence number, and trust domain identifier. Specifically, the first negotiation unit does not use a simple random number or timestamp as the freshness factor. Instead, it uses the current session key as the key for HMAC-SHA256 operations, and the message is a byte string to be derived formed by concatenating the key identifier, negotiation sequence number, and trust domain identifier. The first freshness factor is derived through a hash operation with the key, making its generation cryptographically dependent on the current session key held only by the legitimate communicating parties. Attackers cannot forge a valid freshness factor without possessing the current session key, thus eliminating the possibility of replay attacks at the source. Simultaneously, the key identifier is generated by the second negotiation unit using a truly random number during the complete negotiation phase and returned... The 8-byte random number space ensures that the collision probability of identifiers from different session keys is as low as 2 to the power of -64, guaranteeing that the freshness factors generated by different session keys are cryptographically independent. The negotiation sequence number is maintained by atomic increment operations of the hardware security module, strictly monotonically increasing with each lightweight negotiation. This allows the target warehouse gateway to determine whether a request is a replay by comparing the negotiation sequence number; replay requests with negotiation sequence numbers less than or equal to historical values ​​are directly rejected. The introduction of a trust domain identifier binds the freshness factor to the trust domain of the current target warehouse gateway, preventing attackers from replaying the freshness factor from a legitimate domain-based switching request across domains to gateways in other trust domains. This three-level binding mechanism allows the second negotiation unit, after decrypting the first freshness factor and the current session key, to recalculate and compare the public key binding verification code based on locally available parameters. This enables synchronous verification of the request's freshness and the session key's validity without relying on clock synchronization or additional challenge-response interactions, completing anti-replay verification within a single round trip, balancing the security and efficiency of lightweight negotiation.

[0111] It should be further explained that in this embodiment, the current session key and the generated first freshness factor are encrypted using the public key of the target warehouse gateway, including:

[0112] C101. The first negotiation unit reads the target warehouse gateway public key that has a mapping relationship with the trust domain identifier from the local secure storage area. The target warehouse gateway public key is the RSA-2048 public key distributed by the second negotiation unit during the device registration stage. The first negotiation unit also reads the public key fingerprint value stored in association with the target warehouse gateway public key. The public key fingerprint value is a 32-byte hash value obtained by performing a SHA-256 hash operation on all bytes of the DER encoding of the target warehouse gateway public key.

[0113] In this embodiment, the mapping relationship is stored in a gateway public key mapping table in the local secure storage area. Each record in the gateway public key mapping table contains a 4-byte trust domain identifier field, a 294-byte gateway public key DER encoding field, and a 32-byte public key fingerprint value field. The first negotiation unit uses the 4-byte value of the trust domain identifier as an index to compare the value of the trust domain identifier field in the gateway public key mapping table one by one, and extracts the gateway public key DER encoding field and the public key fingerprint value field from the records that match the comparison. The DER encoding of the target repository gateway public key is a SubjectPublicKeyInfo structure in ASN.1DER format, with a fixed length of 294 bytes. Bytes 1 to 24 are the DER encoding of the algorithm identifier sequence, and bytes 25 to 294 are the BITSTRINGDER encoding of the modulus and public index of the RSA public key. The public key fingerprint value is generated by performing a SHA-256 hash operation on all bytes of the 294-byte DER encoding in sequence to obtain the 32-byte hash value. The public key fingerprint value will undergo an avalanche-like change when any bit-level change occurs in the public key of the target warehouse gateway, enabling the first negotiation unit and the second negotiation unit to detect the consistency of the public key with bit-level precision.

[0114] C102. The first negotiation unit uses 32 bytes of the current session key as the key for HMAC-SHA256 operation and 16 bytes of the first freshness factor as the message for HMAC-SHA256 operation. It performs HMAC-SHA256 operation to obtain a 32-byte output value and takes the first 8 bytes of the 32-byte output value as the public key binding verification code.

[0115] In this embodiment, the execution process of the HMAC-SHA256 operation is the same as that in B103. The first negotiation unit takes the first to eighth bytes of the 32-byte output value as the public key binding verification code. The reason for taking the public key binding verification code as 8 bytes is that the public key binding verification code is used by the second negotiation unit to verify whether the current session key obtained after decryption is consistent with the current session key used when generating the first freshness factor. 8 bytes provide 64 bits of security strength. The probability of an attacker forging a valid public key binding verification code without knowing the current session key is 2 to the power of negative 64. If an attacker tries to pass the verification by exhaustively enumerating the 8-byte value of the public key binding verification code, it will need to try 2 to the power of 63 times on average, which is not feasible within the single renegotiation timeout period.

[0116] C103. The first negotiation unit concatenates the 16 bytes of the first freshness factor, the 8 bytes of the public key binding verification code, and the 32 bytes of the current session key in the order of the first freshness factor first, the public key binding verification code in the middle, and the current session key last to form a 56-byte payload to be encrypted. Using the target warehouse gateway public key as the encryption key, the RSAES-OAEP algorithm with SHA-256 padding scheme is used to perform RSA-2048 encryption operation on the 56-byte payload to be encrypted to obtain a 256-byte payload ciphertext.

[0117] In this embodiment, the first negotiation unit calls the RSA-2048 encryption engine within the hardware security module to perform the RSAES-OAEP encryption operation. The RSA-2048 encryption engine performs the following steps: First, it calls a true random number generator to generate a 256-bit random seed; Second, using SHA-256 as the hash function H and the random seed as input, it performs the OAEP encoding operation, which includes: calculating the SHA-256 hash value of the 56-byte payload to be encrypted as lHash, generating a zero-padding data block DB of the same length as the target RSA modulus length minus 1, concatenating lHash and padding bytes into DB, and inputting the random seed into the MGF1 mask generation function to generate a zero-padding data block DB of the same length as the target RSA modulus length minus 1. A mask of the same length as DB is XORed with DB to obtain maskedDB. maskedDB is then input into the MGF1 mask generation function to generate a mask of the same length as the random seed, which is XORed with the random seed to obtain maskedSeed. maskedSeed is concatenated with maskedDB, and the first byte is set to zero to obtain the encoded message EM. In the third step, a modular exponentiation operation is performed on the encoded message EM using the modulus and public exponent of the target warehouse gateway's public key. The modular exponentiation operation is implemented using a left-to-right binary exponent scanning algorithm and a Montgomery modular multiplier, outputting the 256-byte payload ciphertext. The 56-byte payload to be encrypted is expanded to 256 bytes after OAEP encoding, which is equal to the modulus length of RSA-2048.

[0118] In this embodiment, the MGF1 mask generation function operation process is as follows:

[0119] MGF1 is implemented based on the SHA-256 hash function. The input is a seed byte string and the target mask length, and the output is a mask byte string of a specified length. The specific steps are as follows:

[0120] Divide the target mask length in bytes by 32 and round up to get the maximum number of iterations. The initial value of the counter is 0.

[0121] The counter increments sequentially from 0 to the maximum number of iterations - 1. Each time, the counter is converted into a 4-byte big-endian unsigned integer, concatenated with the input seed byte string, and then a SHA-256 hash operation is performed. The 32-byte hash result obtained each time is concatenated in the order of iteration.

[0122] Extract the number of bytes equal to the length of the target mask from the beginning of the concatenated byte string, and use this as the final output mask.

[0123] In OAEP encoding, the target length is 223 bytes when generating the DB mask and 32 bytes when generating the seed mask. The MGF1 operation is performed according to the steps described above.

[0124] C104. The first negotiation unit concatenates the 32 bytes of the public key fingerprint value, the 256 bytes of the payload ciphertext, and the 1 byte of the renegotiation flag into a 289-byte first ciphertext in the order of the public key fingerprint value first, the payload ciphertext in the middle, and the renegotiation flag last, and sends the first ciphertext to the second negotiation unit.

[0125] In this embodiment, the 1-byte value of the renegotiation flag is set to 0x01 to distinguish it from the message type identifier value 0x02 of the complete Diffie-Hellman key negotiation request message and the frame header identifier value 0x03 of the business data ciphertext frame. The frame structure design, placing the public key fingerprint value in bytes 1 to 32, the payload ciphertext in bytes 33 to 288, and the renegotiation flag in byte 289, allows the second negotiation unit to parse the first ciphertext in the following order after receiving it: first, read bytes 1 to 32 to obtain the public key fingerprint value to verify public key matching; then, read bytes 33 to 288 to obtain the payload ciphertext to perform RSA decryption; and finally, read byte 289 to obtain the renegotiation flag to confirm the message type. The first negotiation unit writes the 289 bytes of the first ciphertext into the transmission buffer of the four-way vehicle wireless communication module, sets the transmission power to a preset maximum value, and transmits it at the current operating channel frequency of the target warehouse gateway. After transmission, a renegotiation response timer is started, with a timeout duration set to 500 milliseconds.

[0126] This process effectively solves the problem of invalid encryption operations and negotiation failure loops caused by the failure or mismatch of the target warehouse gateway's public key during four-way vehicle switching within the domain by introducing a dual binding mechanism of public key fingerprint pre-verification and public key binding verification code in the lightweight, renegotiation payload encryption stage. Specifically, before performing RSA-2048 encryption on the payload to be encrypted, the first negotiation unit reads the target warehouse gateway's public key and its public key fingerprint value mapped to it from the local gateway public key mapping table using the trust domain identifier as the index. This mapping relationship is established during the device registration stage and maintained synchronously with the gateway key update to ensure the consistency between the public key used by the four-way vehicle and the current private key of the target warehouse gateway. At the same time, an 8-byte public key binding verification code is generated using the current session key as the key and the first freshness factor as the message. The first freshness factor, the public key binding verification code, and the current session key are concatenated and then RSAES-OAEP encryption is performed, so that the payload ciphertext is cryptographically bound to the encryption public key, the current session key, and the freshness factor. The second negotiation unit at the receiving end performs a two-stage processing flow: first verifying the public key fingerprint value, then performing RSA decryption. The byte-by-byte XOR verification of the public key fingerprint value takes only microseconds, which can intercept invalid requests caused by public key mismatch with extremely low overhead before RSA decryption, avoiding the waste of millisecond-level RSA private key decryption computation resources. After decryption, by recalculating the public key binding verification code and comparing it with the value extracted from the decryption side, the consistency between the current session key obtained by decryption and the session key used by the four-way vehicle side, as well as the matching of the encryption public key and the decryption private key, can be verified simultaneously. Any mismatch will be detected at this step, preventing attackers from launching forged requests by encrypting with an incorrect public key or replaying old ciphertext. Thus, triple verification of the validity of the encryption public key, the consistency of the session key, and the freshness of the request is achieved with minimal computational cost in a single round trip, ensuring the security and execution efficiency of lightweight key migration.

[0127] It should be further explained that the message authentication code generated in this embodiment for the first ciphertext and the second ciphertext containing the new session key includes:

[0128] D101. The second negotiation unit receives the first ciphertext, reads the 289th byte of the first ciphertext, and compares the value of the 289th byte with the preset renegotiation type constant value 0x01. If the comparison result is not equal, the first ciphertext is discarded and the processing is terminated.

[0129] In this embodiment, after the second negotiation unit obtains all 289 bytes of the first ciphertext from the receive buffer of the wireless communication module, it reads the value of the 289th byte into the comparison register through the internal bus of the hardware security module, reads the preset renegotiation type constant value 0x01 into the reference register, and performs a single-byte equal-value comparison operation. The reason for setting the preset renegotiation type constant value to 0x01 instead of 0x00 is that random errors caused by bit flips during wireless link transmission may cause the 289th byte of an invalid message with an uninitialized memory area or all-zero padding to be exactly 0x00. If 0x00 is used as the renegotiation marker, such invalid messages will be misjudged as renegotiation requests and enter the subsequent public key fingerprint verification process, consuming the computing resources of the hardware security module; the binary representation of 0x01 is 00000001, which differs from the all-zero state 0x00 in all 8 bits. A single bit flip cannot change 0x00 to 0x01, effectively reducing the probability of message type misjudgment caused by random errors in the wireless link.

[0130] D102. If the comparison result is equal, the second negotiation unit reads the first to the 32nd bytes of the first ciphertext as the receiving side public key fingerprint value, reads its own public key fingerprint value stored in the local secure storage area, and performs an XOR operation byte by byte between the 32 bytes of the receiving side public key fingerprint value and the 32 bytes of its own public key fingerprint value. If the XOR result of any byte is not zero, it is determined that the public key fingerprint values ​​do not match, the first ciphertext is discarded and the processing is terminated.

[0131] In this embodiment, the self-owned public key fingerprint value is the 32-byte hash value obtained by the second negotiation unit during the device power-on initialization phase. This hash value is obtained by reading the 294-byte DER encoding of its own RSA-2048 public key from the local secure storage area and performing a SHA-256 hash operation on all bytes of the 294-byte DER encoding. This value remains unchanged throughout the gateway's entire lifecycle unless the gateway performs an RSA key pair replacement operation. The specific execution method of the byte-by-byte XOR operation is as follows: The second negotiation unit sets a loop index i, which increments from 1 to 32. In the i-th loop, the i-th byte of the receiving side public key fingerprint value and the i-th byte of its own public key fingerprint value are loaded into the two 8-bit input terminals of the hardware XOR operation unit, respectively. A bitwise XOR operation is performed, and the 8 bits of the XOR result are compared with zero. The rationale for placing the byte-by-byte XOR verification of the public key fingerprint value before the RSA private key decryption operation is as follows: the total computation time of the 32 single-byte XOR and equality comparison operations of the public key fingerprint value is on the order of microseconds, while the subsequent RSA-2048 private key decryption operation involves 2048-bit modular exponentiation, which takes on the order of milliseconds, a difference of about three orders of magnitude. If the public key stored in the four-way vehicle-side public key mapping table does not match the private key currently used by the target warehouse gateway, or if the attacker uses an incorrect public key to encrypt and construct the first ciphertext, it can be detected and discarded in the microsecond-level pre-verification stage, avoiding the high-overhead invalid RSA decryption operation from occupying the computing resources of the hardware security module.

[0132] D103. If the XOR result of all 32 bytes is zero, the second negotiation unit reads bytes 33 to 288 of the first ciphertext as the payload ciphertext, uses its own stored RSA-2048 private key as the decryption key, uses SHA-256 as the OAEP hash function, performs RSAES-OAEP decryption operation on the 256-byte payload ciphertext to obtain the 56-byte payload to be encrypted, and extracts bytes 1 to 16 in sequence from the 56-byte payload to be encrypted as the first freshness factor on the decryption side, bytes 17 to 24 as the public key binding verification code on the decryption side, and bytes 25 to 56 as the current session key on the decryption side.

[0133] In this embodiment, the second negotiation unit calls the RSA-2048 decryption engine within the hardware security module to execute the RSAES-OAEP decryption operation. The specific execution steps of the RSAES-OAEP decryption operation are as follows: First, perform a modular exponentiation operation on the 256-byte payload ciphertext using the private exponent d and modulus n of the RSA-2048 private key stored in itself. The modular exponentiation operation adopts an accelerated algorithm based on the Chinese Remainder Theorem, calculating partial exponentiation results on the subfields of modulus p and modulus q respectively, and then combining them through CRT to obtain the decoded message EM, where p and q are two prime factors of the modulus n, pre-stored in the secure storage area of ​​the hardware security module; Second, check whether the first byte of the decoded message EM is 0x00. If it is not 0x00, it is determined that the OAEP decoding has failed, the first ciphertext is discarded and the processing is terminated; Third, using SHA-256 as the hash function H, extract the hash from EM according to... The OAEP format separates the maskedSeed and maskedDB fields. The maskedDB is input into the MGF1 mask generation function to generate a mask of the same length as the maskedSeed. This mask is then XORed byte-by-byte with the maskedSeed to obtain the random seed. The random seed is then input into the MGF1 mask generation function to generate a mask of the same length as the maskedDB. This mask is then XORed byte-by-byte with the maskedDB to obtain the data block DB. The first 32 bytes of DB are checked against a preset lHash value obtained by SHA-256 hashing with an empty string as input. If they are not equal, decryption fails and the first ciphertext is discarded. The remaining bytes of DB are then extracted sequentially into the 56-byte payload to be encrypted. The second negotiation unit extracts the first freshness factor from bytes 1 to 16 of the 56-byte payload to be encrypted, the public key binding verification code from bytes 17 to 24, and the current session key from bytes 25 to 56. The byte offsets of these three fields correspond one-to-one with the field order when the first negotiation unit in B106 concatenates the payload to be encrypted.

[0134] D104. The second negotiation unit uses 32 bytes of the current session key of the decryption side as the key for HMAC-SHA256 operation and 16 bytes of the first freshness factor of the decryption side as the message for HMAC-SHA256 operation. It performs one HMAC-SHA256 operation to obtain a 32-byte operation result. The first 8 bytes of the 32-byte operation result are extracted as the verification code bound to the public key of the verification side. The 8 bytes of the verification code bound to the public key of the verification side are XORed with the 8 bytes of the verification code bound to the public key of the decryption side byte by byte. If the XOR result of any byte is not zero, the current session key of the decryption side obtained by decryption is determined to be invalid, the first ciphertext is discarded and the processing is terminated.

[0135] In this embodiment, the HMAC-SHA256 operation performed by the second negotiation unit uses the exact same operation steps and parameters as the HMAC-SHA256 operation performed by the first negotiation unit in B103: using the 32 bytes of the current session key on the decryption side as the key, and the 16 bytes of the first freshness factor on the decryption side as the message, the five-step operation is performed sequentially: XOR the key with iPad, concatenate the message, perform SHA-256 hash, XOR the key with iPad, and concatenate the hash result from the previous step. The method of taking the first 8 bytes of the operation result by binding the verification code to the public key on the verification side is completely consistent with the method used by the first negotiation unit in B105. The byte-by-byte XOR verification of the verification code bound to the public key on the verification side and the verification code bound to the public key on the decryption side achieves a dual verification function: First, it verifies whether the current session key on the decryption side is completely identical to the current session key used by the first negotiation unit in B103 to generate the first freshness factor and in B105 to generate the verification code bound to the public key. If there is any difference of even one bit between the current session key used on the four-way vehicle side and the current session key obtained by decryption on the gateway side, the verification codes bound to the public key generated by the two HMAC-SHA256 operations will be completely different due to the key avalanche effect. Second, it indirectly verifies whether the public key of the target warehouse gateway used for encryption matches the private key of its own RSA-2048 used for decryption. If the two do not match, the current session key on the decryption side obtained by decryption is an invalid random byte string and cannot pass the verification code bound to the public key.

[0136] D105. If the XOR result of all 8 bytes is zero, the second negotiation unit determines the current session key on the decryption side as the valid current session key, uses the 32 bytes of the valid current session key as the key for HMAC-SHA256 operation, and uses the byte string formed by concatenating all 289 bytes of the first ciphertext and all bytes of the second ciphertext containing the new session key in the order of first ciphertext first and second ciphertext last as the message for HMAC-SHA256 operation, performs one HMAC-SHA256 operation, and uses the 32-byte operation result as the message authentication code.

[0137] In this embodiment, after generating the new session key, the second negotiation unit assembles the 32-byte value of the new session key into the second ciphertext. The frame structure of the second ciphertext, together with the remaining fields in the response message except for the message authentication code, constitutes the authentication part of the response message. The second negotiation unit concatenates all 289 bytes of the first ciphertext and all bytes of the second ciphertext in a first-ciphertext-last-ciphertext order, without inserting any delimiters or padding bytes. The total length of the concatenated byte string is 289 bytes plus the length of the second ciphertext. Using the 32 bytes of the valid current session key as the key and the concatenated byte string as the message, the HMAC-SHA256 operation is performed. The resulting 32-byte message authentication code simultaneously covers the complete content of both the first ciphertext and the second ciphertext. This allows the first negotiation unit, upon receiving the response message, to recalculate the message authentication code using the current session key and compare it with the received message authentication code. Simultaneously, it verifies whether the first ciphertext has been tampered with during transmission, whether the second ciphertext has been tampered with during transmission, and whether the response message was indeed generated by the legitimate second negotiation unit holding the valid current session key. This achieves lightweight renegotiation response message integrity protection and source authentication.

[0138] In this embodiment, the specific logic for generating and decrypting the second ciphertext is as follows:

[0139] The second negotiation unit first invokes the true random number generator within the hardware security module to generate a 32-byte true random number as the new session key, simultaneously generating an 8-byte new key identifier and a 4-byte initial negotiation sequence number value of 0x00000001. The 32 bytes of the new session key, the 8 bytes of the new key identifier, and the 4 bytes of the initial negotiation sequence number are concatenated sequentially to form a 44-byte plaintext payload. The 32 bytes of the valid current session key are used as the encryption key for the AES-256 algorithm. A 12-byte true random number is selected as the initial counter value for CTR mode, with the high 8 bytes of the counter having a fixed prefix of 0x0000000000000000 and the low 4 bytes being a big-endian unsigned integer starting from 0. The 44-byte plaintext payload is encrypted using AES-256-CTR mode to obtain 44 bytes of ciphertext data. The 12-byte initial counter value and the 44-byte ciphertext data are then concatenated to form a 56-byte second ciphertext.

[0140] During the decryption of the first negotiation unit, the first 12 bytes are extracted from the second ciphertext as the initial counter value. Using the current session key as the AES-256 key, the same CTR mode is used to perform decryption operations on the last 44 bytes of ciphertext, restoring the new session key, the new key identifier, and the initial negotiation sequence number.

[0141] This process completely eliminates the problem of invalid decryption operation resource consumption caused by renegotiation being marked as a static flag by constructing a five-level hierarchical verification chain on the second negotiation unit side: type identification, public key fingerprint verification, RSA decryption, public key binding verification code verification, and message authentication code generation. Specifically, the first-level filtering uses a single-byte equality comparison of the renegotiation type constant value 0x01 to route non-renegotiation type messages to the corresponding processing branches with minimal computational overhead. Furthermore, 0x01 differs from the all-zero state 0x00 in all 8 bits, and single-bit flipping prevents invalid messages from being mistakenly identified as renegotiation requests, effectively resisting message type misjudgments caused by random errors in the wireless link. The second-level filtering uses a 32-byte byte-by-byte XOR check of the public key fingerprint value, with a total time consumption in the microsecond range, while the subsequent RSA-2048 private key decryption time is in the millisecond range—a difference of three orders of magnitude. In scenarios where public keys do not match or attackers use incorrect public keys to construct malicious ciphertext, this can detect and discard such messages before they enter the high-overhead decryption operation, preventing the hardware security module from being continuously occupied by a large number of invalid decryption requests. The first-byte verification and lHash verification in the RSAES-OAEP decryption operation serve as the third-level filtering. The first level of filtering utilizes the self-verification feature of the OAEP padding format to further intercept ciphertext transmission errors or maliciously constructed invalid ciphertext. The byte-by-byte XOR verification of the public key-bound verification code serves as the fourth level of filtering. It recalculates the verification code using the current session key and the first freshness factor on the decryption side as inputs and compares it with the extracted value on the decryption side, simultaneously completing the dual verification of session key consistency and public key matching. Even if an attacker passes the first three levels of filtering, they cannot pass this step of verification if they do not possess the correct current session key. The final generated message authentication code uses the valid current session key as the key and the concatenated byte string of the first and second ciphertexts as the message, simultaneously covering the complete content of the request and response messages. This allows the first negotiation unit to complete the triple verification of the integrity of the first ciphertext transmission, the integrity of the second ciphertext transmission, and the authenticity of the response message source in a single operation by recalculating the message authentication code after receiving the response. This five-level layered verification mechanism matches the computational overhead of each verification level with the type of attack it intercepts, blocking the vast majority of invalid requests at the lowest overhead level. The complete verification process for legitimate requests only adds microseconds of total latency, maximizing the throughput of the second negotiation unit while ensuring the security of lightweight key migration.

[0142] Example 3

[0143] Please see Figure 3 Another embodiment of the present invention provides: a dynamic key negotiation method based on an improved Diffie-Hellman method, comprising:

[0144] S1. When the four-way vehicle triggers a network switching event, obtain the trust domain identifier of the target warehouse gateway and compare it with the current trust domain identifier stored locally; if the trust domain identifiers are consistent, obtain a valid current session key, encrypt the current session key and the generated first freshness factor with the public key of the target warehouse gateway, construct a first ciphertext carrying a renegotiation flag and send it.

[0145] S2. After receiving the first ciphertext and recognizing the renegotiation marker, the user decrypts the current session key and the first freshness factor using their own private key, and uses the current session key as the key for the message authentication code to generate the first ciphertext and the second ciphertext containing the new session key, and sends a response message containing the message authentication code and the second ciphertext.

[0146] S3. Receive the response message, verify the validity of the message authentication code based on the current session key. If the verification is valid, the first negotiation unit decrypts the second ciphertext with the current session key to obtain a new session key, replaces the current session key in the local secure storage area with the new session key, resets the lightweight negotiation counter to 1, updates the key identifier to the new value corresponding to the new session key, and completes this intra-domain fast key migration.

[0147] S4. If the verification is invalid, the first negotiation unit determines that the lightweight renegotiation has failed, discards the response message, marks the current session key in the local secure storage area as pending verification, and resends the first ciphertext to the target warehouse gateway up to a preset maximum number of retries. If no valid response message is received after the maximum number of retries has been reached, the first negotiation unit determines that the current session key is unavailable on the target warehouse gateway side or that the communication link has been attacked, clears the local security context, erases the current session key from the local secure storage area, terminates the lightweight renegotiation process, and initiates a fully improved Diffie-Hellman key negotiation process based on device fingerprint and gateway public key to re-establish the session key required for secure communication.

[0148] S5. If the trust domain identifiers are inconsistent, the current lightweight renegotiation process is terminated. After a preset number of acquisition windows, the trust domain identifiers of the target warehouse gateway are reacquired and all are determined to be cross-domain switches. Then, the session key and key parameters associated with the current trust domain in the local security context are cleared, and a fully improved Diffie-Hellman key negotiation process based on device fingerprint and gateway public key is initiated.

[0149] Example 4

[0150] An electronic device includes a memory and a processor, the memory storing a computer program, the processor executing the computer program to implement a dynamic key negotiation method based on an improved Diffie-Hellman method.

[0151] A computer-readable storage medium having computer instructions stored thereon that, when executed, perform a dynamic key negotiation method based on an improved Diffie-Hellman method.

[0152] 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.

[0153] 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 dynamic key negotiation system based on an improved Diffie-Hellman algorithm, characterized in that: This includes a first negotiation unit deployed on the four-way vehicle and a second negotiation unit deployed on the warehouse gateway; The first negotiation unit is configured to obtain the trust domain identifier of the target warehouse gateway and compare it with the current trust domain identifier stored locally when the four-way vehicle triggers a network switching event; If the trust domain identifiers match, a valid current session key is obtained, and the current session key and the generated first freshness factor are encrypted with the target warehouse gateway public key to construct a first ciphertext carrying a renegotiation flag and send it. The second negotiation unit is configured to receive the first ciphertext, identify the renegotiation marker, decrypt it using its own private key to obtain the current session key and the first freshness factor, use the current session key as the key for the message authentication code, generate the first ciphertext and the second ciphertext containing the new session key, and send a response message containing the message authentication code and the second ciphertext. The first negotiation unit is further configured to receive the response message, verify the validity of the message authentication code based on the current session key, and if valid, decrypt the second ciphertext to obtain a new session key and replace the current session key; The first negotiation unit is also configured to: if the trust domain identifiers are inconsistent, clear the session key and key parameters associated with the current trust domain in the local security context, and initiate a complete Diffie-Hellman key negotiation process based on the device fingerprint and the gateway public key.

2. The dynamic key negotiation system based on the improved Diffie-Hellman algorithm as described in claim 1, characterized in that, When a network switching event is triggered by a four-way vehicle, obtaining the trust domain identifier of the target warehouse gateway includes: When the first negotiation unit detects that the signal strength value of the current access link is continuously lower than a preset threshold value and the duration reaches a preset duration, it determines that a network handover event is triggered and starts a collection window with a duration of a preset collection duration. Within the acquisition window, the first negotiation unit sequentially receives N beacon frames broadcast by the target warehouse gateway, extracts the candidate trust domain identifier field from the extended area information element of each beacon frame, and records the received signal strength indication value corresponding to the beacon frame, thereby obtaining a one-to-one correspondence between the N candidate trust domain identifiers and the N received signal strength indication values. The N candidate trust domain identifiers are deduplicated to obtain M different candidate trust domain identifiers.

3. The dynamic key negotiation system based on the improved Diffie-Hellman algorithm as described in claim 2, characterized in that, The step of obtaining the trust domain identifier of the target warehouse gateway when the four-way vehicle triggers a network switching event also includes: For each different candidate trust domain identifier, count the number of times it appears in the N candidate trust domain identifiers, and take the arithmetic mean of all the received signal strength indication values ​​corresponding to the candidate trust domain identifier to obtain the average signal strength value corresponding to the candidate trust domain identifier. The candidate trust domain identifier whose ratio of occurrence to N exceeds a preset ratio threshold and whose average signal strength value is the largest is determined as the trust domain identifier of the target warehouse gateway, and the trust domain identifier is compared byte by byte with the current trust domain identifier stored in the local security storage area. If the comparison results are consistent, it is determined that this network handover is an intra-domain handover, and the step of obtaining a valid current session key is executed; If the comparison results are inconsistent, it is determined that this network switch is a cross-domain switch, the current switch process is terminated, and the process waits for the next acquisition window to reacquire the trusted domain identifier.

4. The dynamic key negotiation system based on the improved Diffie-Hellman algorithm as described in claim 3, characterized in that, The process of generating the first freshness factor includes: The first negotiation unit reads the key identifier corresponding to the current session key stored in the local secure storage area. The key identifier is an 8-byte random number generated by the second negotiation unit and sent back to the first negotiation unit through the response message during the complete Diffie-Hellman key negotiation process. The first negotiation unit reads the lightweight negotiation counter that is locally maintained and bound to the current session key, performs an atomic increment operation on the lightweight negotiation counter, and determines the incremented count value as the negotiation sequence number of this negotiation.

5. The dynamic key negotiation system based on the improved Diffie-Hellman algorithm as described in claim 4, characterized in that, The generation process of the first freshness factor also includes: The first negotiation unit concatenates the 8 bytes of the key identifier, the 4 bytes of the negotiation sequence number (big-endian unsigned integer feature), and the trust domain identifier in the order of key identifier first, negotiation sequence number in the middle, and trust domain identifier last to form a byte string to be derived. The 256 bits of the current session key are used as the key for HMAC-SHA256 operation, and the byte string to be derived is used as the message for HMAC-SHA256 operation. The HMAC-SHA256 operation is performed to obtain a 256-bit output value, and the first 16 bytes of the output value are taken as the first freshness factor.

6. The dynamic key negotiation system based on the improved Diffie-Hellman algorithm as described in claim 5, characterized in that, The step of encrypting the current session key and the generated first freshness factor using the target warehouse gateway's public key includes: The first negotiation unit reads the target warehouse gateway public key, which has a mapping relationship with the trust domain identifier, from the local secure storage area. The target warehouse gateway public key is the RSA-2048 public key distributed by the second negotiation unit during the device registration phase. The first negotiation unit also reads the public key fingerprint value stored in association with the target warehouse gateway public key. The public key fingerprint value is a 32-byte hash value obtained by performing a SHA-256 hash operation on all bytes of the 294-byte DER encoded data of the target warehouse gateway public key. The first negotiation unit uses 32 bytes of the current session key as the key for HMAC-SHA256 operation and 16 bytes of the first freshness factor as the message for HMAC-SHA256 operation. It performs HMAC-SHA256 operation to obtain a 32-byte output value and takes the first 8 bytes of the 32-byte output value as the public key binding verification code.

7. The dynamic key negotiation system based on the improved Diffie-Hellman algorithm as described in claim 6, characterized in that, The step of encrypting the current session key and the generated first freshness factor using the target warehouse gateway's public key also includes: The first negotiation unit concatenates the 16 bytes of the first freshness factor, the 8 bytes of the public key binding verification code, and the 32 bytes of the current session key in the order of the first freshness factor first, the public key binding verification code in the middle, and the current session key last to form a 56-byte payload to be encrypted. Using the target warehouse gateway public key as the encryption key, the RSAES-OAEP algorithm with SHA-256 padding scheme is used to perform RSA-2048 encryption operation on the 56-byte payload to be encrypted to obtain a 256-byte payload ciphertext. The first negotiation unit concatenates the 32 bytes of the public key fingerprint value, the 256 bytes of the payload ciphertext, and the 1 byte of the renegotiation flag into a 289-byte first ciphertext in the order of the public key fingerprint value first, the payload ciphertext in the middle, and the renegotiation flag last, and sends the first ciphertext to the second negotiation unit.

8. The dynamic key negotiation system based on the improved Diffie-Hellman algorithm as described in claim 7, characterized in that, Generate a message authentication code that includes the first ciphertext and a second ciphertext containing the new session key, including: Read the 289th byte of the first ciphertext, compare the value of the 289th byte with the preset renegotiation type constant value 0x01, and if the comparison result is not equal, discard the first ciphertext and terminate the process. If the comparison result is equal, then read bytes 1 to 32 of the first ciphertext as the public key fingerprint value of the receiving side, read the public key fingerprint value of itself stored in the local secure storage area, and perform an XOR operation byte by byte between the 32 bytes of the public key fingerprint value of the receiving side and the 32 bytes of the public key fingerprint value of itself. If the XOR result of any byte is not zero, then it is determined that the public key fingerprint values ​​do not match, the first ciphertext is discarded and the processing is terminated.

9. The dynamic key negotiation system based on the improved Diffie-Hellman algorithm as described in claim 8, characterized in that, The message authentication code for generating the first ciphertext and the second ciphertext containing the new session key also includes: If the XOR result of all 32 bytes is zero, the second negotiation unit reads bytes 33 to 288 of the first ciphertext as the payload ciphertext, uses its own stored RSA-2048 private key as the decryption key, and uses SHA-256 as the OAEP hash function to perform RSAES-OAEP decryption operation on the 256-byte payload ciphertext to obtain the 56-byte payload to be encrypted. From the 56-byte payload to be encrypted, bytes 1 to 16 are extracted in sequence as the first freshness factor on the decryption side, bytes 17 to 24 are used as the public key binding verification code on the decryption side, and bytes 25 to 56 are used as the current session key on the decryption side.

10. The dynamic key negotiation system based on the improved Diffie-Hellman algorithm as described in claim 9, characterized in that, The message authentication code for generating the first ciphertext and the second ciphertext containing the new session key also includes: The second negotiation unit uses 32 bytes of the current session key on the decryption side as the key for HMAC-SHA256 operation and 16 bytes of the first freshness factor on the decryption side as the message for HMAC-SHA256 operation. It performs one HMAC-SHA256 operation to obtain a 32-byte operation result. The first 8 bytes of the 32-byte operation result are extracted as the verification code bound to the public key on the verification side. The 8 bytes of the verification code bound to the public key on the verification side are XORed with the 8 bytes of the verification code bound to the public key on the decryption side byte by byte. If the XOR result of any byte is not zero, the current session key on the decryption side obtained by decryption is determined to be invalid, the first ciphertext is discarded and the processing is terminated.

11. The dynamic key negotiation system based on the improved Diffie-Hellman algorithm as described in claim 10, characterized in that, The message authentication code for generating the first ciphertext and the second ciphertext containing the new session key also includes: If the XOR result of all 8 bytes is zero, the second negotiation unit determines the current session key on the decryption side as the valid current session key, uses the 32 bytes of the valid current session key as the key for HMAC-SHA256 operation, and uses the byte string formed by concatenating all 289 bytes of the first ciphertext and all bytes of the second ciphertext containing the new session key in the order of the first ciphertext first and the second ciphertext last as the message for HMAC-SHA256 operation, performs one HMAC-SHA256 operation, and uses the 32-byte operation result as the message authentication code.

12. A dynamic key negotiation method based on an improved Diffie-Hellman algorithm, implemented based on any one of claims 1-11, characterized in that, include: When the four-way vehicle triggers a network switching event, obtain the trust domain identifier of the target warehouse gateway and compare it with the current trust domain identifier stored locally; If the trust domain identifiers match, a valid current session key is obtained, and the current session key and the generated first freshness factor are encrypted with the target warehouse gateway public key to construct a first ciphertext carrying a renegotiation flag and send it. After receiving the first ciphertext and identifying the renegotiation marker, the system uses its own private key to decrypt and obtain the current session key and the first freshness factor. The system then uses the current session key as the key for the message authentication code to generate the first ciphertext and a message authentication code containing the new session key. Finally, the system sends a response message containing the message authentication code and the second ciphertext. Upon receiving the response message, the validity of the message authentication code is verified based on the current session key. If valid, the second ciphertext is decrypted to obtain a new session key, which is then used to replace the current session key. If the trust domain identifiers are inconsistent, the session key and key parameters associated with the current trust domain in the local security context are cleared, and a complete Diffie-Hellman key negotiation process based on the device fingerprint and the gateway public key is initiated.

Images