Secure communication method for edge node and terminal equipment based on dynamic key negotiation

Abstract

The invention relates to a secure communication method for an edge node and terminal equipment based on dynamic key negotiation. The method comprises the following steps: the terminal equipment sends an initial signal when initiating a communication request; the edge node generates a scenarized first key negotiation parameter and feeds back the scenarized first key negotiation parameter after passing dual identity and state verification; after the terminal device decrypts the parameter, a dynamic entropy value is collected by combining a network adaptive sensor, and a second key negotiation parameter associated with the first parameter feature is generated; the two parties calculate session keys based on an ECDH algorithm, and the consistency of the keys is ensured through dynamic entropy verification and Hash comparison; and after the key negotiation succeeds, entering a hierarchical encrypted data transmission stage, and dynamically updating a session key based on a multi-dimensional trigger mechanism. According to the method, through hardware credibility verification, a scenarized key strategy, dynamic entropy enhancement and national secret algorithm adaptation, dynamic management of keys and adaptive matching of terminal resources are achieved, attacks such as equipment counterfeiting and parameter tampering are effectively resisted, and the high-security and compliance requirements in the fields of industrial control and the like are met.

Description

Technical Field

[0001] This invention belongs to the field of communication security technology, and in particular relates to a secure communication method between edge nodes and terminal devices based on dynamic key negotiation. Background Technology

[0002] With the deep integration of the Internet of Things (IoT), the Industrial Internet, and 5G technologies, edge computing, with its advantages of low latency, high bandwidth, and localized data processing, has become the core architecture connecting massive numbers of terminal devices and cloud platforms, and is widely used in key areas such as industrial control, intelligent transportation, and smart homes. The communication data between edge nodes and terminal devices includes not only ordinary business information such as device status and environmental monitoring, but also sensitive content such as industrial equipment control commands, user privacy data, and vehicle safety signals. Its communication security directly determines the reliability and resilience of the entire edge computing system.

[0003] Currently, secure communication between edge nodes and terminal devices mainly relies on traditional encryption technologies, such as pre-shared key encryption, static public key infrastructure encryption, and fixed-period key updates. However, these technologies have gradually revealed significant limitations in practical applications, making them difficult to adapt to the characteristics of edge computing scenarios. Specifically, these limitations are reflected in the following aspects: Rigid key management mechanisms lead to security lagging behind threat evolution: Traditional solutions often adopt key management models that use one key for multiple purposes or update it at fixed intervals. On the one hand, pre-shared keys need to be pre-configured before deployment on edge nodes and terminal devices. Once the key is leaked during transmission or storage, attackers can steal all subsequent communication data for a long time. Moreover, batch updating of keys for a large number of terminal devices is difficult and costly, and is prone to security vulnerabilities such as keys expiring without being updated. On the other hand, fixed-period updates cannot respond to real-time security threats. If edge nodes detect abnormal behaviors such as man-in-the-middle attacks or parameter tampering, they cannot trigger key updates in time, resulting in the continuous existence of attack windows and making it difficult to guarantee security. Poor compatibility of terminal devices makes it difficult to balance security and resource consumption: Terminal devices in edge computing scenarios vary greatly in hardware: industrial sensors and low-power IoT terminals often have limited computing power and limited power consumption, while smart gateways and vehicle terminals have strong computing capabilities. Existing encryption schemes mostly use uniform key lengths and encryption algorithms, failing to consider the resource constraints of terminal devices. For terminals with low computing power, complex key calculations lead to increased device response latency and excessive power consumption; for terminals with high security requirements, fixed low-strength encryption cannot meet the protection requirements of sensitive data, creating a contradiction between security and efficiency. Identity verification relies on a single dimension, making it vulnerable to device impersonation and hardware tampering attacks: Existing identity verification solutions largely depend on a single pattern of device identifier + password, which can only verify the logical identity of the terminal device and cannot confirm the integrity of the device hardware. The legitimacy of the edge node itself also lacks an effective verification mechanism, making it impossible for terminal devices to distinguish whether the connected edge node is a fake node, thus posing a security risk of being deceived by fake edge nodes. Insufficient randomness in key parameters weakens resistance to cracking: During key negotiation, the randomness of parameters directly determines the key's resistance to brute-force attacks. Existing solutions mostly rely on the software random number generator of the terminal device to generate key parameters, whose entropy value is easily affected by the device's operating environment, potentially leading to pseudo-randomness. While some solutions introduce sensor data to enhance randomness, they fail to establish network scenario-sensor type adaptation logic, resulting in high repeatability and poor uniqueness of the collected entropy values, which cannot effectively improve the key's resistance to attacks. The lack of compliance with national cryptographic standards and scenario-specific adaptability makes it difficult to meet industry standards: In sectors with stringent security and compliance requirements, such as finance, energy, and industry, data encryption and verification using national cryptographic algorithms like SM2, SM3, and SM4 are required. Existing solutions primarily rely on international algorithms, offering insufficient support for national cryptographic algorithms or failing to flexibly select algorithm combinations based on specific communication scenarios. This results in solutions that cannot meet industry compliance requirements and have limited applicability. Therefore, there is an urgent need to improve the existing communication process between edge nodes and terminal devices to provide a secure communication method that achieves dynamic key negotiation, adaptive terminal resource management, multi-dimensional identity verification, and highly random parameter generation while complying with national cryptographic standards. Summary of the Invention

[0004] The purpose of this invention is to provide a secure communication method between edge nodes and terminal devices based on dynamic key negotiation, in order to improve the existing communication process between edge nodes and terminal devices, and to provide a secure communication method that realizes dynamic key negotiation, adaptive terminal resources, multi-dimensional identity verification, high randomness parameter generation and complies with national cryptographic standards.

[0005] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows: A secure communication method between edge nodes and terminal devices based on dynamic key negotiation includes the following steps: S1: The terminal device initiates a communication request and sends an initial request signal to the edge node, including device identification information, hardware trusted root certificate digest, current communication scenario identifier, and terminal device status packet; S2: After receiving the initial request signal, the edge node verifies the signal integrity, performs dual identity and status verification, generates the first key negotiation parameter that identifies the current communication scenario, encrypts it, attaches the edge node's hardware certificate digest, and then feeds it back to the terminal device. S3: The terminal device receives the encrypted first key negotiation parameters, decrypts them to obtain the first key negotiation parameters, collects the dynamic entropy value and embeds it into the generation process of the second key negotiation parameters. During the generation process, the characteristics of the first key negotiation parameters are associated, including the first key length determining the initial random number range of the second key. S4: The terminal device obtains the session key based on the first key negotiation parameters and the second key negotiation parameters, using the preset key negotiation algorithm ECDH specified by the scenario-based key policy library; the terminal device generates a key verification packet including the second key negotiation parameters and the original data collected by dynamic entropy, and sends it to the edge node; S5: The edge node receives the encrypted key verification packet, decrypts it using its own private key, performs key consistency verification to achieve key negotiation, and sends a key negotiation success confirmation signal to the terminal device after successful negotiation. S6: The terminal device receives the key negotiation success confirmation signal, compares the session key hash digest sent by the edge node with the local calculation result, and enters the data transmission stage after confirming that they are consistent. S7: Edge nodes and terminal devices repeat steps S2-S5 to update the session key based on the end-to-end associated update triggering mechanism.

[0006] Preferably, the specific process of step S1 is as follows: S11: The terminal device reads the unique hardware identifier from its own non-volatile memory chip, calls the built-in Trusted Platform Module (TPM) chip to generate a trusted root certificate for the current hardware status based on its own security firmware, the terminal device determines and collects the scene identifier, and collects four types of status data in real time through the system interface and sensors, including hardware computing power information, device power, network connection type and security level identifier, to form a terminal device status package. S12: Standardize the information field format of the collected information and assemble it into the main body of the initial request signal in a fixed order. The assembly order is: device identification information; hardware trusted root certificate digest; current communication scenario identifier; terminal device status packet; S13: The terminal device performs anti-tampering processing on the assembled main body: The terminal device calls the local SM3 national cryptographic hash algorithm to perform hash calculation on the main body of the initial request signal and generate an SM3 data digest; the data digest is appended to the end of the initial request signal as an anti-tampering verification field to form a complete initial request signal structure: [Main JSON data block] + [SM3 data digest]; S14: Send the tamper-proof initial request signal to the edge node: The terminal device establishes an initial connection with the edge node through the current access network based on the preset communication protocol; after the transmission is completed, the terminal device enters a waiting state and listens for the response signal fed back by the edge node, that is, the encrypted first key negotiation parameters.

[0007] Preferably, the specific process of dual identity and status verification in step S2 is as follows: S21: Verify the hardware trusted root certificate digest: The edge node calls the preset trusted device certificate library and compares the certificate digest generated by the terminal device TPM with the information stored in the library to confirm that the terminal device hardware has not been tampered with. S22: Verify the device identification information: The edge node queries the preset device whitelist to determine whether the device identification information is in the whitelist and completes the basic identity confirmation; S23: Verify terminal device status packet: The edge node evaluates the terminal device's key calculation capability based on the hardware computing power information in the status packet, and determines the communication security baseline based on the security level identifier.

[0008] Preferably, the specific process of step S3 is as follows: S31: The terminal device receives the encrypted first key negotiation parameters, calls the locally stored trusted edge node certificate store, extracts the edge node hardware certificate digest from the feedback data, queries the pre-stored hardware certificate of the edge node from the trusted edge node certificate store, recalculates the digest value of the pre-stored certificate using the local SM3 national cryptographic algorithm, compares the recalculated digest value with the certificate digest in the feedback data, if they match, the edge node identity is confirmed to be legitimate, if they do not match, the data source is determined to be untrustworthy, the current process is terminated and an authentication failure prompt is sent to the edge node; S32: The terminal device sends a decryption request to the built-in TPM chip, which includes encrypted first key negotiation parameters and decryption authorization instructions; TPM hardware-level decryption execution: After the TPM chip verifies the decryption authorization command, it extracts the private key corresponding to the public key of the terminal device used by the edge node from its own secure storage area, and uses an asymmetric decryption algorithm corresponding to the edge node encryption algorithm to decrypt the encryption parameters; Decryption result verification and extraction: The TPM chip outputs the first key negotiation parameter in plaintext form and generates a hash digest of the parameter using the SM3 algorithm, which is then fed back to the main processor of the terminal device. The main processor of the terminal device compares the hash digest with the preset characteristics of the first key negotiation parameter to confirm that the decrypted data is complete and has not been abnormally tampered with inside the TPM. Finally, the first key negotiation parameter used for subsequent calculations is extracted. S33: The terminal device reads the current network mode from the network connection type in the terminal device status packet, selects the acquisition device according to the preset network-sensor adaptation rules, starts the selected sensor to collect raw data and generate a raw entropy value sequence; compresses the entropy value of the raw sequence, and calculates the final dynamic entropy value by using the SM3 hash algorithm on the standardized raw sequence. S34: The terminal device parses and decrypts the first key negotiation parameters, extracts the core feature parameters, including the first key length, key negotiation algorithm identifier and initial parameter constraints; S35: The terminal device calls the corresponding key parameter generation module based on the key negotiation algorithm identifier to generate initial parameters: a random private key d is generated based on the ECDH algorithm, with the same length as the first key, and the public key Q=d×G is calculated based on the elliptic curve parameter, where G is the base point of the elliptic curve, forming the initial second key negotiation parameter (d, Q). S36: Use the dynamic entropy value as the high 256 bits of the initial random private key d, and supplement the remaining 1792 bits through the local random number generator of the terminal device; Parameter constraint strengthening: Generate constraint factors from the dynamic entropy value through hash operation, and fine-tune the public key in the initial parameters.

[0009] Preferably, the specific process by which the terminal device calculates the session key based on the first key negotiation parameters and the second key negotiation parameters using the preset key negotiation algorithm ECDH specified in the scenario-based key policy library in step S4 is as follows: S41: Perform compliance verification on the first key negotiation parameters and the second key negotiation parameters. If the verification passes, proceed to step S42; otherwise, determine that the parameters are invalid and terminate the calculation. The terminal device extracts the elliptic curve identifier SM2-P-256 specified by the edge node from the first key negotiation parameters, and compares it with the curve type corresponding to the current communication scenario in the scenario-based key policy library to ensure that the curve type is completely consistent. Second key negotiation parameter integrity verification: The terminal device checks whether the second key negotiation parameter contains complete ECDH elements: The terminal device randomly generates a private key d2 and a public key Q2=d2×G, where G is the base point of the elliptic curve, which are extracted from the first key negotiation parameter; at the same time, it verifies that the public key Q2 satisfies the elliptic curve equation to ensure that the parameter generation process has not been tampered with. Key length compliance verification: Extract the key length identifier from the first key negotiation parameter and check whether the private key d2 length of the second key negotiation parameter matches it; S42: The terminal device parses the ECDH public key Q1 generated by the edge node from the first key negotiation parameters. The format is the coordinates of a point on an elliptic curve (x1, y1), and verifies the validity of the public key. S43: Derivation and strengthening of session keys based on the current communication scenario.

[0010] Preferably, the specific process of the terminal device generating and encrypting the key verification packet in step S4 is as follows: S44: Check whether the final session key meets the following requirements: the length is consistent with the length of the derived key specified in the scenario-based key policy library, the randomness entropy value of the key is ≥ the preset threshold, and the key does not have a weak key pattern of all 0s or all 1s. If so, generate a key verification package including the second key negotiation parameter Q2, the original data of dynamic entropy value collection, and the SM3 hash digest of the session key. S45: The terminal device uses the extracted edge node public key to encrypt the key verification packet using the asymmetric encryption algorithm specified in the scenario-based key policy library, and waits to send it to the edge node.

[0011] Preferably, in step S5, the edge node receives the encrypted key verification packet, decrypts it using its own private key, and performs key consistency verification to achieve key negotiation. The specific process is as follows: S51: The edge node receives the encrypted key verification packet, verifies the encrypted header identifier and checksum, and after the verification is successful, the edge node calls its own built-in hardware security module to decrypt: extracts the private key corresponding to the public key from the hardware security module, uses the private key to perform asymmetric decryption on the ciphertext data to obtain the plaintext key verification packet, including the second key negotiation parameters generated by the terminal device, the original dynamic entropy value collection data and the session key SM3 hash digest calculated by the terminal device, and performs integrity verification on the decrypted key verification packet. After passing the integrity verification, step S52 is executed. S52: Edge nodes verify the authenticity and rationality of dynamic entropy values: The edge node extracts the sensor type from the raw dynamic entropy data and performs a matching verification with the network connection type reported by the terminal device. The edge node calls the preset sensor fluctuation threshold library to compare whether the raw fluctuation value sequence sent by the terminal device is within the threshold range. It extracts the collection timestamp of the dynamic entropy value and compares it with the current time of the verification packet received by the edge node to ensure that the time difference is within the preset range. S53: Calculate the session key on the edge node side based on the ECDH algorithm: The edge node extracts the ECDH public key Q2 of the terminal device from the authentication packet; The edge node calls the hardware encryption engine and performs a scalar multiplication operation using its own private key d1 and the terminal public key Q2: Original value of shared key = d1 × Q2; The process of deriving and strengthening the session key based on the current communication scenario in step S43 is executed; S54: Edge nodes confirm the consistency of session keys generated by both parties through hash comparison: The edge node calculates the SM3 hash digest of its own generated session key and compares it with the hash digest sent by the terminal device at the byte level to determine whether they are consistent. If not, it performs difference investigation and re-executes steps S53 and S54. If they are consistent, the key negotiation is successful, a key negotiation success confirmation packet is generated and sent to the terminal device.

[0012] Preferably, the specific process of step S6 is as follows: S61: The terminal device receives the success confirmation packet sent by the edge node, first verifies the signal identifier and CRC32 check code, decrypts the confirmation packet with the session key generated in S4, obtains the SM3 hash digest of the edge node's session key, the key validity period and the initial data packet length suggested by the edge node, calculates the SM3 hash digest of the decrypted success confirmation packet and compares it with the packet content digest attached by the edge node. If they match, step S62 is executed. S62: Read the session key generated in step S4 from the hardware secure storage area, regenerate the hash digest using the SM3 algorithm specified in the scenario-based key policy library, and if it is consistent with the SM3 hash digest of the session key of the edge node, confirm that the keys of both parties are the same and complete the key negotiation loop. If they are inconsistent, freeze the current key, send an alarm to the edge node, and re-execute steps S1-S5.

[0013] The beneficial effects of this invention include: 1. Leveraging terminal TPM certificates and edge node hardware certificates, dual verification of terminal hardware integrity and node identity is achieved to prevent device counterfeiting and identifier cloning. Dynamic entropy values, enhanced by combining SM3 hashing with sensor-collected entropy values ​​adapted to network type to improve key randomness, strengthen the key and improve resistance to brute-force attacks. Multi-dimensional dynamic key updates: Through a periodic + event-triggered mechanism, keys are updated in real time based on response time, attack warnings, and other scenarios, shrinking the attack window to the second level and reducing the risk of data leakage.

[0014] 2. Edge nodes dynamically simplify key parameters for low-resource devices based on terminal computing power and power consumption, shorten negotiation time for low-computing-power terminals, reduce power consumption, and provide differentiated encryption according to terminal security level. Sensitive data is protected by double encryption, and ordinary data is encrypted in a lightweight manner, which improves transmission efficiency compared to full-volume high-strength encryption.

[0015] 3. The key negotiation, encryption, and verification processes are all compatible with the SM series national cryptographic algorithms. No additional modules are required to meet the compliance requirements of finance, industry, and other sectors, reducing adaptation costs. Pre-set differentiated strategies for industrial, vehicle networking, and other scenarios eliminate the need for secondary development and shorten the adaptation cycle.

[0016] 4. Key negotiation and update are fully automated, replacing manual operation, reducing the risk of key leakage. When negotiation fails, logs are automatically recorded and synchronized to the platform, reducing fault location from hours to minutes, and significantly improving operation and maintenance efficiency. Attached Figure Description

[0017] Figure 1 This is a flowchart illustrating the secure communication method between edge nodes and terminal devices based on dynamic key negotiation according to the present invention.

[0018] Figure 2This is a logical schematic diagram of the secure communication method between edge nodes and terminal devices based on dynamic key negotiation according to the present invention. Detailed Implementation

[0019] The following is in conjunction with the appendix Figures 1-2 The present invention will be further described in detail below: Example 1 See appendix Figure 1 and Figure 2 As shown, a secure communication method between edge nodes and terminal devices based on dynamic key negotiation is characterized by the following steps: S1: The terminal device initiates a communication request, sending an initial request signal to the edge node. This signal includes device identification information, a hardware trusted root certificate digest, a current communication scenario identifier, and a terminal device status packet. The hardware trusted root certificate digest is generated by the terminal device's built-in Trusted Platform Module (TPM) and is used to prove the integrity of the device hardware. The current communication scenario identifier includes industrial control scenarios, consumer electronics scenarios, and vehicle-to-everything (V2X) scenarios. The terminal device status includes hardware computing power information, device battery level, network connection type, and security level identifier. Each information field is processed using the terminal device's local SM3 national cryptographic algorithm to generate an overall data digest, which is appended to the end of the initial request signal to ensure that the information has not been tampered with.

[0020] S2: After receiving the initial request signal, the edge node verifies the signal integrity, performs dual identity and status verification, generates the first key negotiation parameter that identifies the current communication scenario, encrypts it, attaches the edge node's hardware certificate digest, and then feeds it back to the terminal device.

[0021] S3: The terminal device receives the encrypted first key negotiation parameters, verifies the hardware certificate digest of the edge node, decrypts the first key negotiation parameters using its own TPM built-in private key, collects dynamic entropy values ​​based on the network connection type-adapted sensor, embeds the dynamic entropy values ​​into the generation process of the second key negotiation parameters, enhances the randomness and uniqueness of the parameters, and associates the characteristics of the first key negotiation parameters fed back in step S2 during the generation process, including the first key length determining the initial random number range of the second key.

[0022] S4: The terminal device obtains the session key based on the first key negotiation parameters and the second key negotiation parameters, using the preset key negotiation algorithm ECDH specified in the scenario-based key policy library; at the same time, the terminal device generates a key verification packet, which includes the second key negotiation parameters, the original dynamic entropy value collection data, and the SM3 hash digest of the session key. The original dynamic entropy value collection data includes the sensor type and collection timestamp; the terminal device uses the edge node public key from step S2 to encrypt the key verification packet. The edge node public key is extracted from the edge node hardware certificate digest and sent to the edge node.

[0023] S5: The edge node receives the encrypted key verification packet, decrypts it using its own private key, performs key consistency verification to achieve key negotiation, and sends a key negotiation success confirmation signal to the terminal device after successful negotiation.

[0024] S6: The terminal device receives a key negotiation success confirmation signal, compares the session key hash digest sent by the edge node with the local calculation result, and enters the data transmission stage after confirming that they are consistent.

[0025] S7: Edge nodes and terminal devices repeat steps S2-S5 to update the session key based on the end-to-end associated update triggering mechanism.

[0026] In this embodiment, the specific process of step S1 is as follows: S11: The terminal device reads a unique hardware identifier from its own non-volatile memory chip. This identifier is unmodifiable information embedded at the factory, including the device serial number (SN), International Mobile Equipment Identity (IMEI, applicable to mobile terminals), IoT device unique identifier (UUID), or hardware MAC address. It then calls the built-in Trusted Platform Module (TPM) chip to generate a trusted root certificate for the current hardware status based on its own security firmware. The TPM first checks the integrity of the terminal device's core hardware components, including the CPU, memory, and encryption chip. After confirming no tampering, it generates a hardware status report. Based on this report, it calculates a hardware trusted root certificate digest using the SM3 national cryptographic hash algorithm. The hash value is 256 bits long, and the digest is bound to the TPM chip's unique identifier to prevent other devices from forging the digest.

[0027] Terminal devices determine and collect scene identifiers in two ways to ensure accurate scene matching: If the terminal device is a dedicated scene device for industrial sensors or vehicle terminals, it reads a fixed scene identifier from a locally preset scene configuration file, such as Industrial Control Scene - V1.0 or Vehicle Networking Scene - Autonomous Driving Mode. If the terminal device is a general scene device such as a smartphone or tablet, it dynamically generates a scene identifier based on the currently running application type, such as an industrial monitoring app or a consumer social app, or a scene mode manually selected by the user, such as Consumer Electronics Scene - Video Call. The terminal device collects four types of status data in real time from the sensors via the system interface, forming a terminal device status package. Hardware computing power information in the terminal device status package is obtained by calling the CPU performance monitoring interface to obtain the current CPU frequency and number of cores, querying the algorithm types supported by the encryption chip, and evaluating the key calculation capability. Device battery power is determined by reading the current remaining battery percentage and battery health through the battery management module to assess the device's battery life. Network connection type is obtained by identifying the currently accessed network type and recording the access base station identifier (applicable to cellular networks) or the router MAC address (applicable to WiFi). S12: Standardize the information field format of the collected information and assemble it into the main body of the initial request signal in a fixed order. The assembly order is: device identification information; hardware trusted root certificate digest; current communication scenario identifier; terminal device status packet. Among them, the device identification information is the primary field for identity recognition and is parsed first. The hardware trusted root certificate digest follows the identity information and is used for hardware integrity verification. The current communication scenario identifier is the core basis for determining the subsequent key strategy. The terminal device status packet is used to assist in adjusting key parameters and communication strategies.

[0028] S13: The terminal device performs anti-tampering processing on the assembled main body: The terminal device calls the local SM3 national cryptographic hash algorithm to perform hash calculation on the main body of the initial request signal (complete JSON data block), generating a 256-bit overall data digest. This data digest is appended to the end of the initial request signal as an anti-tampering verification field, forming a complete initial request signal structure: [Main JSON data block] + [SM3 data digest]. The data digest is stored bound to the main data. If the main data is modified, the digest calculated by subsequent edge nodes will be inconsistent with the appended digest, which can directly identify tampering behavior.

[0029] S14: Send the tamper-proofed initial request signal to the edge node: The terminal device establishes an initial connection with the edge node through the currently accessed network based on a preset communication protocol. The preset communication protocol can be MQTT, CoAP, or a custom industrial protocol. If the network supports QoS (Quality of Service) mechanism, a message confirmation mechanism is enabled to ensure that the initial request signal is successfully received by the edge node. If the network does not support QoS, the success rate of reception is improved by repeatedly sending the request within a short period of time, such as sending it twice at 1-second intervals. After sending, the terminal device enters a waiting state, listening for the response signal from the edge node, i.e., the encrypted first key negotiation parameter in step S2. The waiting timeout is set to 5-10 seconds, which can be adjusted according to the network type, such as 10 seconds for cellular networks and 5 seconds for Ethernet. If no response is received after the timeout, step S1 is re-executed.

[0030] Example 2 Based on Example 1, the specific process of dual identity and status verification in step S2 is as follows: S21: Verify the hardware trusted root certificate digest: The edge node calls the preset trusted device certificate library, compares the certificate digest generated by the terminal device TPM with the pre-stored information in the library, and confirms that the terminal device hardware has not been tampered with. S22: Verify the device identification information: The edge node queries the preset device whitelist to determine whether the device identification information is in the whitelist and completes the basic identity confirmation; S23: Verify terminal device status packet: The edge node evaluates the key calculation capability of the terminal device based on the hardware computing power information in the status packet, and determines the communication security baseline based on the security level identifier; If both dual authentication and status verification pass, the edge node invokes a preset scenario-based key policy library based on the current communication scenario identifier. Different scenarios correspond to different key lengths, negotiation periods, and encryption algorithm combinations. The edge node adjusts the policy parameters based on the evaluation results from step S23; for example, if the computing power is below a threshold, the key length is shortened; if the security level is high, the negotiation period is extended, generating first key negotiation parameters that match the current scenario and the terminal's capabilities. Subsequently, the edge node encrypts the first key negotiation parameters using the terminal device's public key verified in step S21, appends its own hardware certificate digest, and sends it back to the terminal device. The terminal device's public key is extracted from a trusted device certificate library.

[0031] The specific process of step S3 is as follows: S31: The terminal device receives the encrypted first key negotiation parameters, calls the locally stored trusted edge node certificate store, extracts the edge node hardware certificate digest from the feedback data, queries the trusted edge node certificate store for the pre-stored hardware certificate of the edge node, including the trusted root certificate generated by the edge node TPM, recalculates the digest value of the pre-stored certificate using the local SM3 national cryptographic algorithm, compares the recalculated digest value with the certificate digest in the feedback data, if they match, the edge node's identity is confirmed to be legitimate, if they do not match, the data source is determined to be untrustworthy, the current process is terminated, and an authentication failure prompt is sent to the edge node.

[0032] S32: The terminal device sends a decryption request to the built-in TPM chip. The request contains encrypted first key negotiation parameters and decryption authorization instructions. The decryption authorization instructions are generated by the terminal device's operating system kernel and must be verified by the user authorization preset by the TPM, such as a PIN code or biometric authorization, to prevent the TPM from being used illegally.

[0033] TPM hardware-level decryption execution: After the TPM chip verifies the decryption authorization command, it extracts the private key corresponding to the public key of the terminal device used by the edge node in step S2 from its own secure storage area, and uses the asymmetric decryption algorithm corresponding to the edge node encryption algorithm SM2 to decrypt the encryption parameters. This private key is generated by TPM when the terminal device leaves the factory and is only stored inside TPM and cannot be exported to external storage media. Decryption Result Verification and Extraction: After decryption, the TPM chip outputs the first key negotiation parameter in plaintext form and generates a hash digest of the parameter using the SM3 algorithm, which is then fed back to the terminal device's main processor. The terminal device's main processor compares this hash digest with preset characteristics of the first key negotiation parameter, including parameter length and format identifiers. This confirms that the decrypted data is intact and has not been abnormally tampered with internally by the TPM. Finally, the first key negotiation parameter, which is the elliptic curve parameter in the ECDH algorithm, is extracted for subsequent calculations.

[0034] S33: The terminal device reads the current network mode from the recorded terminal device status packet - network connection type, selects the acquisition device according to the preset network-sensor adaptation rules, and ensures that the entropy value acquisition is strongly correlated with the network environment. The terminal device starts the selected sensor and acquires raw data at a preset frequency. The preset frequency can be set to 100Hz. It continuously acquires data for 10-20ms to generate a raw entropy value sequence. Then, the raw sequence is compressed for entropy value. The standardized raw sequence is calculated using the SM3 hash algorithm to generate a 256-bit final dynamic entropy value, ensuring that the entropy value length is fixed and convenient for subsequent parameter embedding.

[0035] S34: The terminal device parses and decrypts the first key negotiation parameters, extracting core feature parameters, including: the first key length, determined by the scenario-based key policy library and the terminal computing power assessment; the key negotiation algorithm identifier, which can be ECDH-SM2, specified by the scenario-based key policy library; and the initial parameter constraints, namely the order of the elliptic curve in the ECDH algorithm.

[0036] S35: The terminal device calls the corresponding key parameter generation module based on the extracted algorithm identifier and generates initial parameters according to the following logic: Generate a random private key d with the same length as the first key, and calculate the public key Q = d×G based on the first key negotiation parameters, where G is the base point of the elliptic curve, to form the initial second key negotiation parameters (d, Q).

[0037] S36: The 256-bit dynamic entropy value is used as the high 256 bits of the 2048-bit initial random private key d. The remaining 1792 bits are supplemented by the local random number generator on the terminal device, ensuring that the initial private key contains both the dynamic environment entropy value and the hardware random entropy value. Parameter constraint strengthening: The dynamic entropy value is hashed to generate a constraint factor, which is used to fine-tune the public key (Q in ECDH) in the initial parameters. The fine-tuned public key Q' = Q × dynamic entropy value, ensuring that the public key and the dynamic entropy value are strongly bound. Even if the initial random number is repeated, the parameter remains unique after embedding the entropy value.

[0038] Example 3 Based on Embodiment 1 or Embodiment 2, the specific process by which the terminal device calculates the session key in step S4 using the preset key negotiation algorithm ECDH specified by the scenario-based key policy library based on the first key negotiation parameters and the second key negotiation parameters is as follows: S41: Perform compliance verification on the first key negotiation parameters and the second key negotiation parameters. If the verification passes, proceed to step S42; otherwise, determine that the parameters are invalid and terminate the calculation. The terminal device extracts the elliptic curve identifier SM2-P-256 specified by the edge node from the first key negotiation parameters obtained by decryption, and compares it with the curve type corresponding to the current communication scenario in the scenario-based key policy library, such as the SM2-P-256 national cryptographic curve specified in the industrial control scenario, to ensure that the curve types are completely consistent; if they are inconsistent, the parameter is determined to be invalid, the calculation is terminated and a curve type mismatch error is reported.

[0039] Second key negotiation parameter integrity verification: The terminal device checks whether the second key negotiation parameter contains complete ECDH elements: private key d2 (randomly generated by the terminal device) and public key Q2=d2×G, where G is the base point of the elliptic curve, extracted from the first key negotiation parameter; at the same time, it verifies whether the public key Q2 satisfies the elliptic curve equation to ensure that the parameter generation process has not been tampered with. The SM2 curve equation is y²=x³+ax+b, where x is the abscissa of a point on the curve, y is the ordinate of a point on the curve, and a and b are curve coefficients. a and b are used to define the curve shape and ensure that the curve is non-singular.

[0040] Key length compliance verification: Extract the key length identifier from the first key negotiation parameter and check whether the private key d2 length of the second key negotiation parameter matches it, that is, a 256-bit private key corresponds to a 256-bit curve, and meets the requirement that the key length in the scenario-based policy library is ≥ the scenario security baseline, such as the 256-bit baseline for the Internet of Vehicles scenario.

[0041] S42: The terminal device parses the ECDH public key Q1 generated by the edge node from the first key negotiation parameters. The format is the coordinates of a point on an elliptic curve (x1, y1), and verifies the validity of the public key, that is, checks whether Q1 is the point at infinity of the elliptic curve (invalid point). If it is the point at infinity, the calculation is terminated; it also verifies whether Q1 satisfies the elliptic curve equation to ensure that the public key has not been tampered with.

[0042] The terminal device invokes its built-in hardware encryption engine, namely the ECDH coprocessor in TPM, and performs a scalar multiplication operation using its own private key d2 and the edge node's public key Q1: the original value of the shared key = d2 × Q1, and the result is a point (x) on an elliptic curve. shared , y sharedThis point can only be calculated by the terminal device and the edge node using their respective private keys. Even if a third party obtains the public keys Q1 and Q2 of both parties, they cannot deduce this point. The x-coordinate x is extracted from the scalar multiplication result. shared As the original value of the shared key, it is usually taken as a byte string of the x-coordinate. For example, a 256-bit curve corresponds to a 32-byte original value, while the y-coordinate is discarded. Only the x-coordinate is used for subsequent key derivation.

[0043] S43: Derivation and strengthening of session keys based on the current communication scenario: The key derivation rules corresponding to the current scenario are read from the scenario-based key policy library, including the key derivation algorithm SM3-KDF (Chinese national cryptographic key derivation function), the length of the derived key, and additional information. The additional information includes scenario identifier, terminal device ID, and timestamp, which are used to enhance the uniqueness of the derivation.

[0044] Input the original value of the shared key x shared Additional information, target key length L, and additional information consisting of scene identifier + terminal device ID + timestamp, converted to byte strings. The target key length L is 32 bytes = 256 bits. The x is then hashed using the SM3 hash algorithm. shared Multiple rounds of hashing are performed with an iteration counter (starting from 1) and additional information until the cumulative output length reaches L. The first L bytes are taken as the derived session key K. The terminal device performs an XOR operation between the collected dynamic entropy value and the session key K to further enhance the randomness of the key: Final session key = K XOR dynamic entropy value, where XOR is the XOR operation. This operation ensures that even if the original shared key value is leaked due to extreme circumstances, attackers cannot directly obtain the final session key used for encryption.

[0045] The specific process of the terminal device generating and encrypting the key verification packet in step S4 is as follows: S44: Check whether the final session key meets the following requirements: the length is consistent with the length of the derived key specified by the scenario strategy, the randomness entropy value of the key is greater than or equal to the preset threshold, and the key does not have a weak key pattern of all 0s or all 1s. If so, generate a key verification packet including the second key negotiation parameter Q2 (the public key of the terminal device, used by the edge node to calculate the shared key), the original dynamic entropy value collection data (including sensor type and timestamp, used by the edge node to verify the validity of the entropy value), and the SM3 hash digest of the session key (used by the edge node to compare key consistency).

[0046] S45: The terminal device uses the extracted edge node public key (parsed from the edge node hardware certificate digest) to encrypt the key verification packet using the asymmetric encryption algorithm specified by the scenario-based strategy, and waits to send it to the edge node.

[0047] In step S5, the edge node receives the encrypted key verification packet, decrypts it using its own private key, and performs key consistency verification to achieve key negotiation. The specific process is as follows: S51: The edge node receives the encrypted key verification packet through the communication link established with the terminal device, following the preset format [encrypted header identifier] + [ciphertext data] + [checksum]. The edge node first verifies the encrypted header identifier and the checksum. The checksum is generated based on the CRC32 algorithm to confirm that the data packet has not been damaged or truncated during transmission. If the format is abnormal, it is directly discarded and the terminal device is notified to retransmit. After the verification is successful, the edge node calls its own built-in hardware security module to decrypt: extract the private key corresponding to the public key from the hardware security module, use the private key to perform asymmetric decryption on the ciphertext data, and obtain the plaintext key verification packet, including the second key negotiation parameters (ECDH public key Q2) generated by the terminal device, the original dynamic entropy data (including sensor type, timestamp, and original fluctuation value sequence), and the session key SM3 hash digest calculated by the terminal device. The edge node then performs an integrity verification on the decrypted key verification packet. After passing the integrity verification, step S52 is executed.

[0048] S52: Edge nodes verify the authenticity and rationality of dynamic entropy values: Edge nodes extract sensor types from the raw dynamic entropy data and perform matching verification with the network connection types reported by the terminal devices. For example, 5G networks correspond to base station signal sensors, and WiFi networks correspond to gyroscopes. Edge nodes call a preset sensor fluctuation threshold library to compare the raw fluctuation value sequence sent by the terminal device with the threshold range. The sensor fluctuation threshold library stores the normal fluctuation ranges for different sensors, such as ±15° for gyroscope angle change and ±20dBm for base station signal strength fluctuation. The acquisition timestamp of the dynamic entropy value is extracted and compared with the current time of the verification packet received by the edge node to ensure the time difference is within a preset range. The preset range can be set to ≤5 seconds and can be dynamically adjusted according to network latency. If the time difference exceeds the preset range, the entropy value is determined to be historical reused data, i.e., not real-time acquisition, and the verification fails.

[0049] S53: Calculate the session key on the edge node side based on the ECDH algorithm: The edge node extracts the ECDH public key Q2 of the terminal device (the coordinates of a point on the elliptic curve (x2, y2)) from the verification packet and performs the following verifications: Check whether Q2 is the point at infinity of the elliptic curve (invalid point). Verify whether Q2 satisfies the elliptic curve equation specified in step S2, i.e., the SM2 curve y²=x³+ax+b, and confirm that the order of Q2 is consistent with the order of the curve base point G.

[0050] The edge node invokes the hardware encryption engine, using its own private key d1 and the terminal's public key Q2 to perform a scalar multiplication operation: original value of the shared key = d1 × Q2. The private key d1 is generated in step S2 and stored in the hardware security module.

[0051] The process of deriving and strengthening the session key based on the current communication scenario in step S43 is executed; S54: Edge nodes confirm that the session keys generated by both parties are consistent through hash comparison: The edge node calculates the SM3 hash digest of its own generated session key and compares it byte-by-byte with the hash digest sent by the terminal device to determine if they are consistent. If not, it performs a difference check and re-executes steps S53 and S54. If they are consistent, the key negotiation is successful, and a key negotiation success confirmation packet is generated, including the SM3 hash digest of the edge node's session key, the session key validity period, and the initial data packet length. This packet is then sent to the terminal device. The session key validity period is specified by the scenario-based key policy library and can be set to 30 minutes. The initial encrypted communication packet length is obtained based on the network type in the terminal device's status packet.

[0052] The specific process of step S6 is as follows: S61: The terminal device receives the success confirmation packet sent by the edge node through the established communication link. First, it verifies the signal identifier and CRC32 check code to ensure that the data is not damaged and the source is compliant. Then, it decrypts the confirmation packet with the session key generated in S4, obtains the SM3 hash digest of the edge node's session key, the key validity period, and the initial data packet length suggested by the edge node. It calculates the SM3 hash digest of the decrypted success confirmation packet and compares it with the packet content digest attached by the edge node. If they match, it executes step S62. S62: Read the session key generated in step S4 from the hardware secure storage area, regenerate the hash digest using the SM3 algorithm specified by the scenario policy, and if it is consistent with the SM3 hash digest of the session key of the edge node, confirm that the keys of both parties are the same and complete the key negotiation loop. If they are inconsistent, freeze the current key, send an alarm to the edge node, and re-execute steps S1-S5.

Claims

1. A secure communication method between edge nodes and terminal devices based on dynamic key negotiation, characterized in that, Includes the following steps: S1: The terminal device initiates a communication request and sends an initial request signal to the edge node, including device identification information, hardware trusted root certificate digest, current communication scenario identifier, and terminal device status packet; S2: After receiving the initial request signal, the edge node verifies the signal integrity, performs dual identity and status verification, generates the first key negotiation parameter that identifies the current communication scenario, encrypts it, attaches the edge node's hardware certificate digest, and then feeds it back to the terminal device. S3: The terminal device receives the encrypted first key negotiation parameters, decrypts them to obtain the first key negotiation parameters, collects the dynamic entropy value and embeds it into the generation process of the second key negotiation parameters. During the generation process, the characteristics of the first key negotiation parameters are associated, including the first key length determining the initial random number range of the second key. S4: The terminal device obtains the session key based on the first key negotiation parameters and the second key negotiation parameters, using the preset key negotiation algorithm ECDH specified by the scenario-based key policy library; the terminal device generates a key verification packet including the second key negotiation parameters and the original data collected by dynamic entropy, and sends it to the edge node; S5: The edge node receives the encrypted key verification packet, decrypts it using its own private key, performs key consistency verification to achieve key negotiation, and sends a key negotiation success confirmation signal to the terminal device after successful negotiation. S6: The terminal device receives the key negotiation success confirmation signal, compares the session key hash digest sent by the edge node with the local calculation result, and enters the data transmission stage after confirming that they are consistent. S7: Edge nodes and terminal devices repeat steps S2-S5 to update the session key based on the end-to-end associated update triggering mechanism.

2. The secure communication method between edge nodes and terminal devices based on dynamic key negotiation according to claim 1, characterized in that, The specific process of step S1 is as follows: S11: The terminal device reads the unique hardware identifier from its own non-volatile memory chip, calls the built-in Trusted Platform Module (TPM) chip to generate a trusted root certificate for the current hardware status based on its own security firmware, the terminal device determines and collects the scene identifier, and collects four types of status data in real time through the system interface and sensors, including hardware computing power information, device power, network connection type and security level identifier, to form a terminal device status package. S12: Standardize the information field format of the collected information and assemble it into the main body of the initial request signal in a fixed order. The assembly order is: device identification information; hardware trusted root certificate digest; current communication scenario identifier; terminal device status packet; S13: The terminal device performs anti-tampering processing on the assembled main body: The terminal device calls the local SM3 national cryptographic hash algorithm to perform hash calculation on the main body of the initial request signal and generate an SM3 data digest; the data digest is appended to the end of the initial request signal as an anti-tampering verification field to form a complete initial request signal structure: [Main JSON data block] + [SM3 data digest]; S14: Send the tamper-proof initial request signal to the edge node: The terminal device establishes an initial connection with the edge node through the current access network based on a preset communication protocol; After the transmission is completed, the terminal device enters a waiting state and listens for the response signal from the edge node, which is the encrypted first key negotiation parameter.

3. The secure communication method between edge nodes and terminal devices based on dynamic key negotiation according to claim 2, characterized in that, The specific process of dual identity and status verification in step S2 is as follows: S21: Verify the hardware trusted root certificate digest: The edge node calls the preset trusted device certificate library and compares the certificate digest generated by the terminal device TPM with the information stored in the library to confirm that the terminal device hardware has not been tampered with. S22: Verify the device identification information: The edge node queries the preset device whitelist to determine whether the device identification information is in the whitelist and completes the basic identity confirmation; S23: Verify terminal device status packet: The edge node evaluates the terminal device's key calculation capability based on the hardware computing power information in the status packet, and determines the communication security baseline based on the security level identifier.

4. The secure communication method between edge nodes and terminal devices based on dynamic key negotiation according to claim 1, characterized in that, The specific process of step S3 is as follows: S31: The terminal device receives the encrypted first key negotiation parameters, calls the locally stored trusted edge node certificate store, extracts the edge node hardware certificate digest from the feedback data, queries the pre-stored hardware certificate of the edge node from the trusted edge node certificate store, recalculates the digest value of the pre-stored certificate using the local SM3 national cryptographic algorithm, compares the recalculated digest value with the certificate digest in the feedback data, if they match, the edge node identity is confirmed to be legitimate, if they do not match, the data source is determined to be untrustworthy, the current process is terminated and an authentication failure prompt is sent to the edge node; S32: The terminal device sends a decryption request to the built-in TPM chip, which includes encrypted first key negotiation parameters and decryption authorization instructions; TPM hardware-level decryption execution: After the TPM chip verifies the decryption authorization command, it extracts the private key corresponding to the public key of the terminal device used by the edge node from its own secure storage area, and uses an asymmetric decryption algorithm corresponding to the edge node encryption algorithm to decrypt the encryption parameters; Decryption result verification and extraction: The TPM chip outputs the first key negotiation parameter in plaintext form and generates a hash digest of the parameter using the SM3 algorithm, which is then fed back to the main processor of the terminal device. The main processor of the terminal device compares the hash digest with the preset characteristics of the first key negotiation parameter to confirm that the decrypted data is complete and has not been abnormally tampered with inside the TPM. Finally, the first key negotiation parameter used for subsequent calculations is extracted. S33: The terminal device reads the current network mode from the network connection type in the terminal device status packet, selects the acquisition device according to the preset network-sensor adaptation rules, starts the selected sensor to collect raw data and generate a raw entropy value sequence; compresses the entropy value of the raw sequence, and calculates the final dynamic entropy value by using the SM3 hash algorithm on the standardized raw sequence. S34: The terminal device parses and decrypts the first key negotiation parameters, extracts the core feature parameters, including the first key length, key negotiation algorithm identifier and initial parameter constraints; S35: The terminal device calls the corresponding key parameter generation module based on the key negotiation algorithm identifier to generate initial parameters: an initial random private key d is generated based on the ECDH algorithm, with the same length as the first key, and the public key Q=d×G is calculated based on the elliptic curve parameter, where G is the base point of the elliptic curve, forming the initial second key negotiation parameter (d, Q). S36: Use the dynamic entropy value as the high 256 bits of the initial random private key d, and supplement the remaining 1792 bits through the local random number generator of the terminal device; Parameter constraint strengthening: Generate constraint factors from the dynamic entropy value through hash operation, and fine-tune the public key in the initial parameters.

5. The secure communication method between edge nodes and terminal devices based on dynamic key negotiation according to claim 1, characterized in that, In step S4, the terminal device calculates the session key based on the first key negotiation parameters and the second key negotiation parameters using the preset key negotiation algorithm ECDH specified in the scenario-based key policy library. The specific process is as follows: S41: Perform compliance verification on the first key negotiation parameters and the second key negotiation parameters. If the verification passes, proceed to step S42; otherwise, determine that the parameters are invalid and terminate the calculation. The terminal device extracts the elliptic curve identifier SM2-P-256 specified by the edge node from the first key negotiation parameters, and compares it with the curve type corresponding to the current communication scenario in the scenario-based key policy library to ensure that the curve type is completely consistent. Second key negotiation parameter integrity verification: The terminal device checks whether the second key negotiation parameter contains complete ECDH elements: The terminal device randomly generates a private key d2 and a public key Q2=d2×G, where G is the base point of the elliptic curve, which are extracted from the first key negotiation parameter; at the same time, it verifies that the public key Q2 satisfies the elliptic curve equation to ensure that the parameter generation process has not been tampered with. Key length compliance verification: Extract the key length identifier from the first key negotiation parameter and check whether the private key d2 length of the second key negotiation parameter matches it; S42: The terminal device parses the ECDH public key Q1 generated by the edge node from the first key negotiation parameters. The format is the coordinates of a point on an elliptic curve (x1, y1), and verifies the validity of the public key. S43: Derivation and strengthening of session keys based on the current communication scenario.

6. The secure communication method between edge nodes and terminal devices based on dynamic key negotiation according to claim 5, characterized in that, The specific process of the terminal device generating and encrypting the key verification packet in step S4 is as follows: S44: Check whether the final session key meets the following requirements: the length is consistent with the length of the derived key specified in the scenario-based key policy library, the randomness entropy value of the key is ≥ the preset threshold, and the key does not have a weak key pattern of all 0s or all 1s. If so, generate a key verification package including the second key negotiation parameter Q2, the original data of dynamic entropy value collection, and the SM3 hash digest of the session key. S45: The terminal device uses the extracted edge node public key to encrypt the key verification packet using the asymmetric encryption algorithm specified in the scenario-based key policy library, and waits to send it to the edge node.

7. The secure communication method between edge nodes and terminal devices based on dynamic key negotiation according to claim 5, characterized in that, In step S5, the edge node receives the encrypted key verification packet, decrypts it using its own private key, and performs key consistency verification to achieve key negotiation. The specific process is as follows: S51: The edge node receives the encrypted key verification packet, verifies the encrypted header identifier and checksum, and after the verification is successful, the edge node calls its own built-in hardware security module to decrypt: extracts the private key corresponding to the public key from the hardware security module, uses the private key to perform asymmetric decryption on the ciphertext data to obtain the plaintext key verification packet, including the second key negotiation parameters generated by the terminal device, the original dynamic entropy value collection data and the session key SM3 hash digest calculated by the terminal device, and performs integrity verification on the decrypted key verification packet. After passing the integrity verification, step S52 is executed. S52: Edge nodes verify the authenticity and rationality of dynamic entropy values: The edge node extracts the sensor type from the raw dynamic entropy data and performs a matching verification with the network connection type reported by the terminal device. The edge node calls the preset sensor fluctuation threshold library to compare whether the raw fluctuation value sequence sent by the terminal device is within the threshold range. It extracts the collection timestamp of the dynamic entropy value and compares it with the current time of the verification packet received by the edge node to ensure that the time difference is within the preset range. S53: Calculate the session key on the edge node side based on the ECDH algorithm: The edge node extracts the ECDH public key Q2 of the terminal device from the authentication packet; The edge node calls the hardware encryption engine and performs a scalar multiplication operation using its own private key d1 and the terminal public key Q2: Original value of shared key = d1 × Q2; The process of deriving and strengthening the session key based on the current communication scenario in step S43 is executed; S54: Edge nodes confirm the consistency of session keys generated by both parties through hash comparison: The edge node calculates the SM3 hash digest of its own generated session key and compares it with the hash digest sent by the terminal device at the byte level to determine whether they are consistent. If not, it performs difference investigation and re-executes steps S53 and S54. If they are consistent, the key negotiation is successful, a key negotiation success confirmation packet is generated and sent to the terminal device.

8. The secure communication method between edge nodes and terminal devices based on dynamic key negotiation according to claim 7, characterized in that, The specific process of step S6 is as follows: S61: The terminal device receives the success confirmation packet sent by the edge node, first verifies the signal identifier and CRC32 check code, decrypts the confirmation packet with the session key generated in S4, obtains the SM3 hash digest of the edge node's session key, the key validity period and the initial data packet length suggested by the edge node, calculates the SM3 hash digest of the decrypted success confirmation packet and compares it with the packet content digest attached by the edge node. If they match, step S62 is executed. S62: Read the session key generated in step S4 from the hardware secure storage area, regenerate the hash digest using the SM3 algorithm specified in the scenario-based key policy library, and if it is consistent with the SM3 hash digest of the session key of the edge node, confirm that the keys of both parties are the same and complete the key negotiation loop. If they are inconsistent, freeze the current key, send an alarm to the edge node, and re-execute steps S1-S5.

Images