Security communication method for edge node and terminal device based on dynamic key agreement

Abstract

The application relates to a secure communication method of an edge node and a terminal device based on dynamic key negotiation, wherein an initial signal is sent when the terminal device initiates a communication request; the edge node generates a first key negotiation parameter after double identity and state verification and feeds back the first key negotiation parameter; after the terminal device decrypts the parameter, dynamic entropy values are collected by combining a network adaptive sensor to generate a second key negotiation parameter associated with the first parameter characteristics; a session key is calculated by both parties based on an ECDH algorithm, and the key consistency is ensured through dynamic entropy value verification and hash comparison; after the key negotiation succeeds, a hierarchical encrypted data transmission stage is entered, and the session key is dynamically updated based on a multi-dimensional trigger mechanism. Through hardware trusted verification, a scene-based key strategy, dynamic entropy value enhancement and a national secret algorithm adaptation, dynamic management of the key and adaptive matching of terminal resources are realized, attacks such as device impersonation and parameter tampering are effectively resisted, and the high security and compliance requirements in the field of industrial control and the like are met.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of communication security, and particularly relates to a security communication method for edge nodes and terminal devices based on dynamic key negotiation. BACKGROUND

[0002] With the deep integration of the Internet of Things, the Industrial Internet and 5G technology, edge computing has become the core architecture connecting massive terminal devices and cloud platforms due to its advantages of low latency, high bandwidth and localized data processing, and is widely used in key fields such as industrial control, intelligent transportation and smart home. The communication data between edge nodes and terminal devices contains not only ordinary business information such as device status and environmental monitoring, but also sensitive content such as industrial device control instructions, user privacy data and vehicle safety signals, and the communication security directly determines the reliability and risk resistance of the entire edge computing system.

[0003] Currently, the security 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 update, but these technologies gradually expose significant limitations in adapting to the characteristics of edge computing scenarios in practical applications, which are embodied in the following aspects:

[0004] Key management mechanism is rigid and security lags behind threat evolution: Traditional schemes mostly adopt a key management mode of one key for multiple uses or fixed period update: On the one hand, pre-shared keys need to be pre-configured before the deployment of edge nodes and terminal devices, and once the keys are leaked in the transmission or storage process, attackers can steal all subsequent communication data for a long time, and the batch update of keys for massive terminal devices is difficult and costly, which is prone to security vulnerabilities such as expired keys not being updated; on the other hand, fixed period update cannot respond to real-time security threats, and if edge nodes detect abnormal behaviors such as man-in-the-middle attacks and parameter tampering, they cannot trigger key update in time, resulting in the existence of attack windows and difficulty in ensuring security.

[0005] Poor adaptability of terminal devices, difficult to balance security and resource consumption: The hardware of terminal devices in edge computing scenarios varies greatly: industrial sensors, low-power Internet of Things terminals and other devices often have limited computing power and power supply, while intelligent gateways, vehicle terminals and other devices have strong computing power. Existing encryption schemes mostly use uniform key length and encryption algorithms without considering the resource constraints of terminal devices. For low-computing-power terminals, complex key calculation will increase device response delay and power consumption too quickly; for high-security-demand terminals, fixed low-intensity encryption cannot meet the protection requirements of sensitive data, forming a contradiction between security and efficiency.

[0006] The identity verification dimension is single, and is vulnerable to device impersonation and hardware tampering attacks: the identity verification of existing schemes mainly depends on a single mode of device identification + password, which can only verify the logical identity of the terminal device and cannot confirm the integrity of the device hardware. The edge node itself lacks an effective verification mechanism for its identity legitimacy, and the terminal device cannot distinguish whether the connected edge node is a fake node, which poses a security risk of fake edge node deception.

[0007] The key parameters lack randomness and have weak anti-cracking ability: in the key negotiation process, the randomness of the parameters directly determines the anti-brute force cracking ability of the key. Existing schemes mainly rely on the software random number generator of the terminal device to generate key parameters, and the entropy value is easily affected by the device running environment, which may cause pseudo-random problems; although some schemes introduce sensor data to enhance randomness, they do not establish an adaptation logic for network scenarios-sensor types, resulting in high repeatability and poor uniqueness of the collected entropy value, which cannot effectively improve the anti-attack ability of the key.

[0008] The national secret compliance and scenario adaptation are missing, and it is difficult to meet the industry standards: in the fields of finance, energy, industry and other strict security compliance requirements, it is required to use SM2, SM3, SM4 and other national secret algorithms for data encryption and verification. Existing schemes mainly use international algorithms, and the support for national secret algorithms is insufficient, or the algorithm combination is not selected flexibly combined with specific communication scenarios, which makes the scheme unable to meet the industry compliance requirements and the scope of application is limited. Therefore, it is urgent to improve the communication process between the existing edge node and the terminal device to provide a secure communication method that realizes dynamic key negotiation, adaptive terminal resources, multi-dimensional identity verification, high randomness parameter generation and compliance with national secret standards. SUMMARY

[0009] The purpose of the present application is to provide a secure communication method for edge nodes and terminal devices based on dynamic key negotiation, which improves the communication process between the existing edge node and the terminal device to provide a secure communication method that realizes dynamic key negotiation, adaptive terminal resources, multi-dimensional identity verification, high randomness parameter generation and compliance with national secret standards.

[0010] To solve the above technical problems, the technical solutions adopted by the present application are as follows:

[0011] The secure communication method for edge nodes and terminal devices based on dynamic key negotiation comprises the following steps:

[0012] S1: the terminal device initiates a communication request and sends an initial request signal including device identification information, hardware trusted root certificate digest, current communication scenario identification and terminal device state package to the edge node;

[0013] S2: After the edge node receives the initial request signal and verifies the signal integrity, it performs double identity and state verification, generates the first key negotiation parameter of the current communication scenario identifier, encrypts it, and then adds the hardware certificate digest of the edge node to feedback to the terminal device;

[0014] S3: The terminal device receives the encrypted first key negotiation parameter, decrypts it to obtain the first key negotiation parameter, collects dynamic entropy values, and embeds the generation process of the second key negotiation parameter. In the generation process, the first key negotiation parameter characteristics are associated, including the first key length determining the initial random number range of the second key;

[0015] S4: The terminal device obtains the session key through the preset key negotiation algorithm ECDH specified by the scenario-based key strategy library based on the first key negotiation parameter and the second key negotiation parameter. The terminal device generates a key verification package including the second key negotiation parameter and the original collection data of the dynamic entropy value, and sends it to the edge node;

[0016] S5: The edge node receives the encrypted key verification package, 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;

[0017] 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 consistency;

[0018] S7: The edge node and the terminal device repeat steps S2-S5 to update the session key based on the update trigger mechanism associated with the whole process.

[0019] Preferably, the specific process of step S1 is as follows:

[0020] S11: The terminal device reads the unique hardware identifier from the non-volatile storage chip, calls the built-in trusted platform module (TPM) chip to generate a trusted root certificate based on the current hardware state of the secure firmware, determines and collects the scenario identifier, and collects four types of state data including hardware computing power information, device power, network connection type, and security level identifier through the system interface and sensor in real time. Form a terminal device state package;

[0021] S12: Standardize the information field format of the collected information, and assemble it into the main part of the initial request signal in a fixed order. The assembly order is: device identifier information; hardware trusted root certificate digest; current communication scenario identifier; terminal device state package;

[0022] S13: The terminal device performs anti-tampering processing on the assembled main body part: the terminal device calls a local SM3 national cryptographic hash algorithm to perform hash calculation on the initial request signal main body to generate an SM3 data digest; the data digest is attached as an anti-tampering check field to the end of the initial request signal to form a complete initial request signal structure: [main body JSON data block] + [SM3 data digest];

[0023] S14: Send the initial request signal after anti-tampering processing to the edge node: the terminal device establishes an initial connection with the edge node based on a preset communication protocol through the current access network; after sending is completed, the terminal device enters a waiting state and listens to a response signal, i.e., an encrypted first key negotiation parameter, fed back by the edge node.

[0024] Preferably, the specific process of the double identity and state verification in step S2 is as follows:

[0025] S21: Verify the hardware trusted root certificate digest: the edge node calls a preset trusted device certificate library to compare the certificate digest generated by the terminal device TPM with the pre-stored information in the library to confirm that the terminal device hardware has not been tampered with;

[0026] S22: Verify the device identification information: the edge node queries a preset device white list to determine whether the device identification information is in the white list to complete basic identity confirmation;

[0027] S23: Verify the terminal device state package: the edge node evaluates the terminal device key calculation capability based on the hardware computing power information in the state package and determines the communication security baseline based on the security level identifier.

[0028] Preferably, the specific process of step S3 is as follows:

[0029] S31: The terminal device receives the encrypted first key negotiation parameter, calls the locally stored trusted edge node certificate library, extracts the edge node hardware certificate digest in the feedback data, queries the pre-stored hardware certificate of the edge node from the trusted edge node certificate library, recalculates the digest value of the pre-stored certificate through the local SM3 national cryptographic algorithm, compares the recalculated digest value with the certificate digest in the feedback data, and if they are consistent, confirms that the edge node identity is legal, and if they are inconsistent, determines that the data source is not trustworthy, terminates the current process, and sends an identity verification failure prompt to the edge node;

[0030] S32: The terminal device sends a decryption request to the built-in TPM chip, and the request includes the encrypted first key negotiation parameter and a decryption authorization instruction;

[0031] TPM hardware level decryption execution: after the TPM chip verifies the decryption authorization instruction, the private key corresponding to the terminal device public key used by the edge node is extracted from the self-security storage area, and the non-symmetric decryption algorithm corresponding to the encryption algorithm of the edge node is used to decrypt the encrypted parameters;

[0032] 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 through the SM3 algorithm, which is fed back to the terminal device main processor; the terminal device main processor 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 tampered with internally by the TPM, and finally extracts the first key negotiation parameter for subsequent calculation;

[0033] S33: the terminal device reads the current network mode from the network connection type of the terminal device state package, selects the acquisition device according to the preset network-sensor adaptation rule, starts the selected sensor to collect original data and generates an original entropy value sequence; the original sequence is compressed by entropy value, and the standardized original sequence is calculated by the SM3 hash algorithm to generate the final dynamic entropy value;

[0034] S34: the terminal device parses the first key negotiation parameter obtained by decryption, and extracts the core feature parameters, including the first key length, the key negotiation algorithm identifier and the initial parameter constraint condition;

[0035] S35: the terminal device generates initial parameters based on the key negotiation algorithm identifier to call the corresponding key parameter generation module: generates a random private key d based on the ECDH algorithm, with the same length as the first key length, and calculates the public key Q=d×G based on the elliptic curve parameter, G is the elliptic curve base point, to form the initial second key negotiation parameter (d, Q);

[0036] S36: the dynamic entropy value is used as the high 256 bits of the initial random private key d, and the remaining 1792 bits are supplemented by the terminal device local random number generator; parameter constraint strengthening: the dynamic entropy value is generated by hash operation to generate a constraint factor, and the public key in the initial parameter is fine-tuned.

[0037] Preferably, the specific process of calculating the session key by the terminal device based on the first key negotiation parameter, the second key negotiation parameter and the preset key negotiation algorithm ECDH specified by the scene key strategy library in step S4 is as follows:

[0038] S41: compliance verification is performed on the first key negotiation parameter and the second key negotiation parameter, if yes, step S42 is executed, if no, it is determined that the parameters are invalid, and the calculation is terminated:

[0039] The terminal device extracts the elliptic curve identifier SM2-P-256 specified by the edge node from the first key negotiation parameter, and compares the curve type corresponding to the current communication scenario in the scenario-based key policy library to ensure that the curve types are completely consistent.

[0040] Second key negotiation parameter integrity check: the terminal device checks whether the second key negotiation parameter contains complete ECDH elements: the private key d2 and the public key Q2=d2×G generated by the terminal device, and the public key Q2 satisfies the elliptic curve equation to ensure that the parameter generation process has not been tampered with.

[0041] Key length compliance check: extract the key length identifier in the first key negotiation parameter, and check whether the private key d2 length of the second key negotiation parameter matches it.

[0042] S42: The terminal device parses the ECDH public key Q1 generated by the edge node from the first key negotiation parameter, which is in the format of point coordinates (x1, y1) on the elliptic curve, and verifies the validity of the public key.

[0043] S43: Session key derivation and strengthening based on the current communication scenario.

[0044] Preferably, the specific process of the terminal device generating and encrypting the key verification package in step S4 is as follows:

[0045] S44: Check whether the final session key meets the following conditions: the length is consistent with the derived key length specified by the scenario-based key policy library, the randomness entropy value of the key is greater than or equal to the preset threshold, the key does not appear the weak key mode of all 0 and all 1, if so, generate a key verification package including the second key negotiation parameter Q2, the dynamic entropy value original collection data and the SM3 hash digest of the session key;

[0046] S45: The terminal device uses the extracted edge node public key to encrypt the key verification package through the asymmetric encryption algorithm specified by the scenario-based key policy library, and waits to send to the edge node.

[0047] Preferably, the specific process of the edge node receiving the encrypted key verification package and performing key consistency verification to achieve key negotiation after decrypting with its own private key in step S5 is as follows:

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

[0049] S52: Edge nodes verify the authenticity and rationality of dynamic entropy values:

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

[0051] 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;

[0052] The process of deriving and strengthening the session key based on the current communication scenario in step S43 is executed;

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

[0054] Preferably, the specific process of step S6 is as follows:

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

[0056] S62: read the session key generated in step S4 from the hardware security storage area, regenerate the hash digest with the SM3 algorithm specified in the key policy library, if consistent with the session key SM3 hash digest of the edge node, confirm that the keys of both parties are the same, complete the key agreement closed loop, if not consistent, freeze the current key, issue an alarm to the edge node, and re-execute steps S1-S5.

[0057] The beneficial effects of the present application include:

[0058] 1. Based on the terminal TPM certificate and the edge node hardware certificate, terminal hardware integrity and node identity double verification are realized to prevent device impersonation and identity cloning. The dynamic entropy value of the key is enhanced by adapting the sensor collection entropy value to the network type and combining SM3 hash to improve the randomness of the key, which improves the anti-brute force cracking ability. Multi-dimensional dynamic key update: through the periodic + event triggering mechanism, the key is updated in real time in response to scenarios such as response time, attack warning, etc., the attack window is reduced to seconds, and the risk of data leakage is reduced.

[0059] 2. The edge node dynamically simplifies the key parameters of low-resource devices based on terminal computing power and power, shortens the low-computing-power terminal negotiation time consumption and power consumption, differentiates encryption according to terminal security levels, double-protects sensitive data, and lightly encrypts ordinary data, which improves transmission efficiency compared to full-amount high-strength encryption.

[0060] 3. The key agreement, encryption, and verification links are all adapted to the SM series national secret algorithm, which can meet the compliance requirements of finance, industry, etc. without additional modules, reduces adaptation cost, and pre-sets differential strategies for industrial and Internet of Vehicles scenarios without secondary development, shortening the adaptation period.

[0061] 4. The key agreement and update are fully automated, replacing manual operation and reducing the risk of key leakage. When the agreement fails, logs are automatically recorded and synchronized with the platform, fault location is reduced from hours to minutes, and operation and maintenance efficiency is significantly improved. BRIEF DESCRIPTION OF DRAWINGS

[0062] Figure 1 It is a flowchart of the security communication method between the edge node and the terminal device based on dynamic key agreement of the present application.

[0063] Figure 2 It is a logic diagram of the security communication method between the edge node and the terminal device based on dynamic key agreement of the present application. DETAILED DESCRIPTION

[0064] The following will be described in conjunction with the accompanying Figures 1-2 Further detailed description of the present application:

[0065] Example 1

[0066] Reference is made to the accompanying Figure 1 andFigure 2 The edge node and terminal device security communication method based on dynamic key negotiation is characterized in that it comprises the following steps:

[0067] S1: The terminal device initiates a communication request and sends an initial request signal including device identification information, hardware trusted root certificate digest, current communication scenario identification and terminal device state package to the edge node. 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 device hardware integrity. The current communication scenario identification includes industrial control scenario, consumer electronics scenario and vehicle-to-vehicle network scenario, and the terminal device state contains hardware computing power information, device power, network connection type and security level identification. The information fields are generated into an overall data digest by the terminal device's local SM3 national encryption algorithm and are attached to the end of the initial request signal to ensure that the information has not been tampered with.

[0068] S2: After receiving the initial request signal, the edge node verifies the signal integrity, performs double identity and state verification, generates the first key negotiation parameter of the current communication scenario identification, encrypts it, attaches the hardware certificate digest of the edge node and feeds it back to the terminal device.

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

[0070] S4: The terminal device obtains the session key through the preset key negotiation algorithm ECDH specified by the scenario-based key policy library based on the first key negotiation parameter and the second key negotiation parameter; at the same time, the terminal device generates a key verification package containing the second key negotiation parameter, dynamic entropy value raw data and SM3 hash digest of the session key, and the dynamic entropy value raw data includes sensor type and collection timestamp; the terminal device encrypts the key verification package using the public key of the edge node in step S2, which is extracted from the edge node hardware certificate digest, and sends it to the edge node.

[0071] S5: The edge node receives the encrypted key verification package, 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.

[0072] 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 consistency.

[0073] S7: The edge node and the terminal device repeat steps S2-S5 to update the session key based on the update trigger mechanism of the full-process association.

[0074] In this embodiment, the specific process of step S1 is as follows:

[0075] S11: The terminal device reads a unique hardware identifier from a non-volatile storage chip of the terminal device. The identifier is unmodifiable information fixed at the factory of the device and includes a device serial number SN, an international mobile equipment identity (IMEI, applicable to mobile terminals), an Internet of Things device unique identifier UUID, or a hardware MAC address. A built-in trusted platform module (TPM) generates a trusted root certificate of the current hardware state based on the self-security firmware. The TPM first detects the integrity of the core hardware components of the terminal device including the CPU, memory, and encryption chip, and generates a hardware state report after confirming that there is no tampering. Based on the report, a hardware trusted root certificate digest is calculated through an SM3 national secret hash algorithm, the hash value length of which is 256 bits, and the digest is bound with the unique identifier of the TPM chip to prevent other devices from forging the digest.

[0076] The terminal device determines and collects the scene identifier in the following two ways to ensure the accuracy of scene matching: if the terminal device is a special scene device of an industrial sensor or a vehicle-mounted terminal, a fixed scene identifier is read from a local preset scene configuration file, such as an industrial control scene-V1.0 or a vehicle networking scene-automatic driving mode. If the terminal device is a general scene device such as a smartphone or a tablet computer, a scene identifier is dynamically generated through the type of the currently running application program, such as an industrial monitoring APP or a consumer social APP or a scene mode selected manually by the user, such as a consumer electronics scene-video call. The terminal device collects four types of state data in real time through a system interface and a sensor to form a terminal device state package. The hardware computing power information in the terminal device state package is obtained by calling a CPU performance monitoring interface to obtain the current CPU frequency and core number, querying the algorithm type supported by the encryption chip, and evaluating the key calculation capability. The device power is read by a battery management module to obtain the current remaining power percentage and the battery health degree to judge the device endurance capability. The network connection type is obtained by identifying the currently accessed network type, recording the access base station identifier (applicable to cellular networks) or the router MAC address (applicable to WiFi).

[0077] S12: Standardize the collected information in the information field format, and assemble it into the main part of the initial request signal in a fixed order: device identification information; hardware trusted root certificate digest; current communication scenario identification; terminal device state package. 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 identification is the core basis for determining the subsequent key strategy. The terminal device state package is used to assist in adjusting the key parameters and communication strategy.

[0078] S13: The terminal device performs anti-tampering processing on the assembled main part: the terminal device calls the local SM3 national secret hash algorithm to perform hash calculation on the initial request signal main part (complete JSON data block) to generate a 256-bit overall data digest. The data digest is attached to the end of the initial request signal as an anti-tampering check field, forming a complete initial request signal structure: [main JSON data block] + [SM3 data digest]. The data digest is stored in association with the main data. If the main data is modified, the digest calculated by the subsequent edge node will not match the attached digest, and the tampering behavior can be directly identified.

[0079] S14: Send the initial request signal after anti-tampering processing to the edge node:

[0080] The terminal device establishes an initial connection with the edge node based on a pre-set communication protocol through the currently accessed network. The pre-set communication protocol can be MQTT or CoAP or a custom industrial protocol. If the network supports QoS (Quality of Service) mechanism, enable message confirmation mechanism to ensure that the initial request signal is successfully received by the edge node. If the network does not support QoS, improve the reception success rate by repeatedly sending within a short time, such as sending 2 times with an interval of 1 second. After sending, the terminal device enters a waiting state and listens for the response signal from the edge node, i.e. the encrypted first key negotiation parameter in step S2. The waiting timeout time is set to 5-10 seconds, which can be adjusted according to the network type, such as 10 seconds for cellular network and 5 seconds for Ethernet. If the response is not received within the timeout time, re-execute step S1.

[0081] Embodiment 2

[0082] On the basis of embodiment 1, the specific process of double identity and state verification in step S2 is as follows:

[0083] S21: Verify the hardware trusted root certificate digest: the edge node calls the pre-set trusted device certificate library to compare the certificate digest generated by the terminal device TPM with the pre-stored information in the library to confirm that the terminal device hardware has not been tampered with.

[0084] 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;

[0085] S23: Verify the terminal device state package: the edge node evaluates the terminal device key calculation capability based on the hardware computing power information in the state package, and determines the communication security baseline based on the security level identifier;

[0086] If the double identity verification and state verification are passed, the edge node calls the preset scene key strategy library based on the current communication scene identifier, different scenes correspond to different key lengths, negotiation periods and encryption algorithm combinations, and adjusts the strategy parameters combined with the evaluation results of step S23, such as shortening the key length if the computing power is lower than the threshold, and prolonging the negotiation period if the security level is high, to generate the first key negotiation parameter matching the current scene and terminal capability. Then the edge node encrypts the first key negotiation parameter with the terminal device public key verified in step S21, and feeds back to the terminal device after adding the edge node's own hardware certificate digest, and the terminal device public key is extracted from the trusted device certificate library.

[0087] The specific process of step S3 is as follows:

[0088] S31: The terminal device receives the encrypted first key negotiation parameter, calls the locally stored trusted edge node certificate library, extracts the edge node hardware certificate digest in the feedback data, queries the pre-stored hardware certificate of the edge node from the trusted edge node certificate library, including the trusted root certificate generated by the edge node TPM, recalculates the digest value of the pre-stored certificate by the local SM3 national secret algorithm, compares the recalculated digest value with the certificate digest in the feedback data, and if they are consistent, it is confirmed that the edge node identity is legal, if they are not consistent, it is determined that the data source is not trusted, the current process is terminated and an identity verification failure prompt is sent to the edge node.

[0089] S32: The terminal device sends a decryption request to the built-in TPM chip, which contains the encrypted first key negotiation parameter and the decryption authorization instruction, and the decryption authorization instruction is generated by the terminal device operating system kernel, which needs to pass through the user authorization verification preset by the TPM, such as PIN code or biometric authorization, to prevent the TPM from being called illegally.

[0090] TPM hardware level decryption execution: After the TPM chip verifies the decryption authorization instruction, it extracts the private key corresponding to the terminal device public key 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 encrypted parameter. The private key is generated by the TPM when the terminal device is shipped and is only stored in the TPM, which cannot be exported to external storage media.

[0091] 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 through the SM3 algorithm and feeds back to the terminal device main processor. The terminal device main processor compares the hash digest with the preset characteristics of the first key negotiation parameter, including parameter length, format identifier, to confirm that the decrypted data is complete and has not been tampered with internally by the TPM, and finally extracts the first key negotiation parameter which can be used for subsequent calculation, the first key negotiation parameter is the elliptic curve parameter in the ECDH algorithm.

[0092] S33: The terminal device reads the current network mode from the recorded terminal device state package-network connection type, selects the acquisition device according to the preset network-sensor adaptation rule, ensures the strong correlation between entropy value acquisition and network environment, starts the selected sensor, acquires raw data at a preset frequency, which can be set to 100Hz, and generates a raw entropy value sequence by continuously acquiring for 10-20ms; then the raw sequence is compressed for entropy value, and the standardized raw sequence is calculated through the SM3 hash algorithm to generate a 256-bit final dynamic entropy value, ensuring that the entropy value length is fixed, facilitating subsequent parameter embedding.

[0093] S34: The terminal device parses the first key negotiation parameter obtained by decryption, and extracts core feature parameters, including: first key length, determined by the scene-based key strategy library and terminal computing power evaluation; key negotiation algorithm identifier, which can be ECDH-SM2, specified by the scene-based key strategy library; initial parameter constraint condition, order of elliptic curve in ECDH algorithm.

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

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

[0096] Embodiment 3

[0097] On the basis of Embodiment 1 or Embodiment 2, the specific process in which the terminal device calculates the session key based on the first key negotiation parameter, the second key negotiation parameter, and through a preset key negotiation algorithm ECDH specified by the scenario-based key policy library in step S4 is as follows:

[0098] S41: Perform compliance verification on the first key negotiation parameter and the second key negotiation parameter, and if yes, perform step S42, and if no, determine that the parameters are invalid, and terminate the calculation:

[0099] The terminal device extracts the edge node specified elliptic curve identifier SM2-P-256 from the decrypted first key negotiation parameter, 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 secret curve specified for the industrial control scenario, to ensure that the curve types are completely consistent; if not, determine that the parameters are invalid, terminate the calculation, and feed back the curve type mismatch error.

[0100] 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, G being an elliptic curve base point extracted from the first key negotiation parameter; at the same time, verify whether the public key Q2 satisfies the elliptic curve equation to ensure that the parameter generation process has not been tampered with, and the SM2 curve equation is y² = x³ + ax + b, where x is the horizontal coordinate of a point on the curve, y is the vertical coordinate of a point on the curve, a and b are both curve coefficients, a and b are used to define the curve shape, and the curve is ensured to be non-singular.

[0101] Key length compliance verification: Extract the key length identifier in the first key negotiation parameter, and check whether the private key d2 length of the second key negotiation parameter matches it, i.e., 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 scene security baseline, such as the 256-bit baseline for the Internet of Vehicles scenario.

[0102] S42: The terminal device parses the ECDH public key Q1 generated by the edge node from the first key negotiation parameter, in the format of point coordinates (x1, y1) on the elliptic curve, and verifies the validity of the public key, i.e., checks whether Q1 is an infinitely distant point (invalid point) of the elliptic curve, and if it is, terminates the calculation; verify whether Q1 satisfies the elliptic curve equation to ensure that the public key has not been tampered with.

[0103] The terminal device calls the built-in hardware encryption engine, i.e., the ECDH coprocessor in the TPM, to perform scalar multiplication operation with its own private key d2 and the edge node public key Q1: shared key raw value = d2 × Q1, and the operation result is a point (x shared , y shared), which can only be calculated by the terminal device and the edge node through their respective private keys, and a third party cannot derive the point even if they obtain the public keys Q1 and Q2 of the two parties. The x-coordinate x is extracted from the scalar multiplication result shared As the original value of the shared key, the byte string of the x-coordinate is usually taken, such as 32 bytes of the original value corresponding to a 256-bit curve, and the y-coordinate is discarded, and only the x-coordinate is used for subsequent key derivation.

[0104] S43: Session key derivation and strengthening based on the current communication scenario:

[0105] The key derivation rule corresponding to the current scenario is read from the scenario-based key policy library, including the key derivation algorithm SM3-KDF (national secret key derivation function), the length of the derived key, and additional information. The additional information includes the scenario identifier, the terminal device ID, and the timestamp, which is used to enhance the uniqueness of the derivation.

[0106] The input shared key original value x shared , additional information, and target key length L, the additional information is the scenario identifier + terminal device ID + timestamp, converted into a byte string, and the target key length L is 32 bytes = 256 bits. The x shared is subjected to multiple rounds of hash operations with the iteration counter (starting from 1) and the additional information until the cumulative output length reaches L, and 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: the final session key = K XOR dynamic entropy value, XOR is the XOR operation. This operation ensures that even if the shared key original value is leaked due to extreme circumstances, the attacker cannot directly obtain the final session key used for encryption.

[0107] The specific process of the terminal device generating and encrypting the key verification package in step S4 is as follows:

[0108] S44: Check whether the final session key meets the following conditions: the length is consistent with the derived key length specified by the scenario-based policy, the randomness entropy value of the key is greater than or equal to the preset threshold, and the key does not appear in the weak key mode of all 0 and all 1. If so, generate a key verification package including the second key agreement parameter Q2 (terminal device public key, for the edge node to calculate the shared key), the original collection data of the dynamic entropy value (including the sensor type and the timestamp, for the edge node to verify the validity of the entropy value), and the SM3 hash digest of the session key (for the edge node to compare the consistency of the key).

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

[0110] The edge node receives the encrypted key verification package in step S5, decrypts it using its own private key, and then performs key consistency verification to realize the specific process of key negotiation as follows:

[0111] S51: The edge node receives the encrypted key verification package through the communication link established with the terminal device, and follows the preset format [encrypted header identifier] + [ciphertext data] + [check code]. The edge node first verifies the encrypted header identifier and the check code. The check code is generated based on the CRC32 algorithm to confirm that the data package is not damaged or truncated during transmission. If the format is abnormal, it is directly discarded and the terminal device is notified to resend. After the verification is passed, the edge node calls the built-in hardware security module for decryption: 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, obtains the plaintext form of the key verification package, including the second key negotiation parameter (ECDH public key Q2) generated by the terminal device, the dynamic entropy value original collection data (including sensor type, timestamp, and original fluctuation value sequence), and the session key SM3 hash digest calculated by the terminal device, and performs integrity verification on the decrypted key verification package. After passing, step S52 is performed.

[0112] S52: The edge node verifies the authenticity and reasonableness of the dynamic entropy value:

[0113] The edge node extracts the sensor type from the dynamic entropy value original data and performs matching verification with the network connection type reported by the terminal device, such as 5G network corresponding to base station signal sensor and WiFi network corresponding to gyroscope. The edge node calls the preset sensor fluctuation threshold library to compare whether the original fluctuation value sequence sent by the terminal device is within the threshold range. The sensor fluctuation threshold library stores the normal fluctuation range of different sensors, such as gyroscope angle change threshold ± 15° and base station signal strength fluctuation threshold ± 20 dBm. The collection timestamp of the dynamic entropy value is extracted and compared with the current time when the edge node receives the verification package to ensure that the time difference is within the preset range, which can be set to ≤ 5 seconds and can be dynamically adjusted according to network delay. If the time difference exceeds the preset range, it is determined that the entropy value is historical reuse data, i.e. non-real-time collection, and the verification fails.

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

[0115] The edge node calls the hardware encryption engine to perform a scalar multiplication operation with the terminal public key Q2 using the private key d1 of the edge node: the shared key original value = d1 x Q2. The private key d1 of the edge node is generated in step S2 and stored in the hardware security module.

[0116] The process of session key derivation and strengthening based on the current communication scenario in step S43 is performed.

[0117] S54: The edge node confirms that the session keys generated by both parties are consistent through hash comparison:

[0118] The edge node calculates the SM3 hash digest of the session key generated by the edge node and compares it with the hash digest sent by the terminal device at the byte level to determine whether they are consistent. If not, the difference is investigated and steps S53 and S54 are re-executed. If yes, the key agreement is successful, and a key agreement success confirmation packet including the SM3 hash digest of the session key of the edge node, the session key validity period, and the initial data packet length is generated and 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 packet length for initial encryption communication is obtained based on the network type in the terminal device status packet.

[0119] The specific process of step S6 is as follows:

[0120] S61: The terminal device receives the success confirmation packet sent by the edge node through the established communication link, first verifies the signal identifier and CRC32 check code to ensure that the data is not damaged and the source is compliant, decrypts the confirmation packet using the session key generated in S4 to obtain the session key SM3 hash digest of the edge node, 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, and if they are consistent, step S62 is performed.

[0121] S62: The session key generated in step S4 is read from the hardware security storage area, and the hash digest is regenerated using the SM3 algorithm specified by the scene policy. If the session key SM3 hash digest of the edge node is consistent, it is confirmed that the keys of both parties are the same, the key agreement closed loop is completed, if not consistent, the current key is frozen, an alarm is sent to the edge node, and steps S1-S5 are re-executed.

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