Multi-protocol suite compatible node security interconnection negotiation protocol

Abstract

The invention discloses a node security interconnection negotiation protocol compatible with a multi-protocol suite, and aims to solve the problems of insufficient node protocol compatibility, low negotiation efficiency, rigid security policy and the like in a heterogeneous network. The protocol adopts a three-layer separated negotiation architecture, and cross-protocol security interconnection is realized through four stages of discovery of protocol acquisition node capability through a transmission layer, unification of standardized parameters of a security session model, dynamic decision making of a policy-driven negotiation engine, capability discovery exchange, policy negotiation, parallel handshake and verification and dynamic protocol switching. The method is deployed between an application layer and an existing security protocol layer, an existing network structure does not need to be transformed, compatibility of multiple protocols such as TLS and IPsec is supported, optimal protocols and parameters can be dynamically adapted based on the network state and resources, communication security, instantaneity and continuity are guaranteed, and the method is suitable for heterogeneous node interconnection scenes such as an intelligent power grid.

Description

Multi-protocol suite compatible node secure interconnection negotiation protocol Technical Field

[0001] This invention relates to the field of network communication security technology. Specifically, it is a multi-protocol suite compatible node secure interconnection negotiation technology applicable to heterogeneous network environments. It aims to solve the compatibility, negotiation efficiency and dynamic security adjustment problems caused by differences in security protocol stacks among heterogeneous nodes such as IoT devices, mobile terminals and cloud servers. It can be widely used in scenarios with high requirements for communication security, real-time performance and continuity, such as smart grids, industrial internet and IoT. Background Technology

[0002] In the current heterogeneous network environment, there are a variety of node types such as IoT devices, mobile terminals, and cloud servers, and the security protocol stacks supported by each node are significantly different.

[0003] Traditional secure interconnection mechanisms such as TLS / SSL, IPsec, and WireGuard use fixed protocol suites, which have many problems: First, protocol heterogeneity means that different nodes only support specific protocols, resulting in insufficient compatibility; second, existing negotiation mechanisms such as ALPN lack cross-layer unified negotiation capabilities, resulting in low efficiency; third, security policies are rigid and cannot dynamically adjust cipher suites according to the real-time network environment; and fourth, forward compatibility is lacking, requiring a full network upgrade to deploy new protocols, resulting in high migration costs.

[0004] Terminology and Abbreviations: TLS: Transport Layer Security, a cryptographically based secure communication protocol used to establish a secure channel between communicating parties, ensuring the confidentiality, integrity, and authentication of data transmission. The document mentions TLS version 1.3 as the underlying security protocol support. IPsec: Internet Protocol Security, a suite of protocols for secure communication at the network layer, protecting IP packet transmission through encryption and authentication technologies. The document lists it as one of the mainstream supported security protocols, adapting to the high security requirements of high-performance devices. WireGuard: A lightweight Virtual Private Network Protocol (VPN), characterized by its simplicity, efficiency, and low resource consumption. The document incorporates it into the existing protocol layer as a low-level support option for multi-protocol compatibility negotiation. DTLS: Datagram Transport Layer Security, an extension of the TLS protocol, suitable for connectionless transmission scenarios such as UDP. The document supports DTLS version 1.3, adapting to the real-time data transmission needs of IoT-constrained devices. ALPN: Application Layer Protocol Negotiation, an extension protocol for TLS... The handshake process negotiates the application layer protocol, but the document points out that it lacks cross-layer unified negotiation capabilities, which is one of the improvement targets of this invention; TLDP: Transport Layer Discovery Protocol, one of the core components of the three-layer architecture proposed in this invention, based on standardized meta-protocol identifiers, realizes bidirectional protocol capability detection and core information collection between nodes, forming a structured capability dataset; USSM: Unified Security Session Model, one of the core components of the three-layer architecture proposed in this invention, constructs a generalized abstract framework, uniformly maps the key parameters of different security protocols to standardized descriptors, and realizes cross-protocol parameter mutual recognition; PDNE: Policy-Driven Negotiation Engine, one of the core components of the three-layer architecture proposed in this invention, integrates game theory multi-objective decision-making logic and real-time risk assessment mechanism, and outputs the optimal security protocol and parameter combination; CAP_FRAME: Capability Frame, a structured data frame containing fields such as version number, random number, protocol capability list, and security policy Merkle root hash, used in the document for bidirectional interaction of protocol capabilities between communicating nodes;CSPRNG: Cryptographically Secure Pseudo-Random Number Generator, an algorithm or device capable of generating cryptographically secure random numbers. In the documentation, it's used to generate the 16-byte nonce in CAP_FRAME to defend against replay attacks. nonce: Number Used Once, a one-time random value generated by CSPRNG. In the documentation, it's used to verify the validity of CAP_FRAME and prevent replay attacks. IANA: Internet Assigned Numbers Authority, responsible for the allocation and standardization of global Internet protocol-related resources. The unique identifiers of cipher suites in the documentation all follow IANA standards. CVE: Common Vulnerabilities and Exposures, a publicly available vulnerability database used for the standardized naming and recording of security vulnerabilities in software, hardware, and protocols. In the documentation, it's used to count the historical exposure counts of cryptographic algorithms. NVD: National Vulnerability Database. Database: A vulnerability database maintained by the National Institute of Standards and Technology (NIST), providing detailed vulnerability descriptions, risk scores, and other data. The document uses it to obtain vulnerability statistics for cryptographic algorithms. VCG: Vickrey-Clarke-Groves Mechanism, a multi-objective optimization decision-making mechanism. The document uses an improved VCG mechanism to construct a comprehensive utility function to achieve optimal protocol selection. SHA3-256: Secure Hash Algorithm 3-256, a cryptographic hash function that outputs a 256-bit hash value. The document uses it for protocol consistency verification to ensure that both parties have consistent optimal protocols and parameter configurations. AES: Advanced Encryption Standard, a symmetric encryption algorithm. The document mentions variants such as AES-128-CCM and AES-256-GCM, which are mainstream cryptographic suites supporting encrypted data transmission between nodes. ChaCha20-Poly1305: A combined encryption scheme (ChaCha20 Stream Cipher +...). The Poly1305 Message Authentication Code contains the stream cipher ChaCha20 and the message authentication code Poly1305. It is described in the document as a lightweight cipher suite that is suitable for IoT-restricted devices.SM4-GCM: GCM mode (SM4 Block Cipher in Galois / CounterMode) of the SM4 algorithm, a symmetric encryption algorithm independently designed in my country. GCM mode combines encryption and authentication functions and is listed in the document as one of the cipher suites supported by high-performance devices. 3DES: Triple Data Encryption Standard, a symmetric encryption algorithm that enhances security through three DES encryptions. The document assigns it a low security weight coefficient (0.5) and considers it a reference option for traditional cipher suites. UDP: User Datagram Protocol, a connectionless transport layer protocol with low latency. The document uses it for data transmission in the DTLS protocol and for CAP_FRAME interaction. QUIC: Quick UDP Internet Connections, a UDP-based transport layer protocol that integrates the advantages of TCP, TLS, and other protocols. The document lists it as a low-level transport layer protocol option to adapt to the transmission needs of different network scenarios. Summary of the Invention

[0005] This invention proposes a node secure interconnection negotiation protocol compatible with multiple protocol suites. To address the problems of insufficient protocol compatibility and low negotiation efficiency of heterogeneous network nodes, it adopts a "three-layer separation negotiation architecture" and is deployed between the application layer and the existing security protocol layer without modifying the existing network structure.

[0006] The protocol discovery node capability is acquired through the transport layer. After standardization by a unified secure session model, the optimal protocol is dynamically selected by a policy-driven negotiation engine.

[0007] The protocol is implemented in four phases: capability discovery and exchange, policy negotiation, parallel handshake and verification, and dynamic protocol switching. It integrates mechanisms such as quantitative evaluation and multi-objective optimization, taking into account security, efficiency and resource overhead. It supports dynamic switching of the protocol during the session and can realize seamless interconnection of heterogeneous nodes such as IoT devices and servers. It is suitable for scenarios with high requirements for communication security and real-time performance, such as smart grids.

[0008] To address the problems mentioned in the background technology, this invention proposes a multi-protocol suite compatible node secure interconnection negotiation protocol. The implementation process of the protocol is as follows: 1. Innovative Protocol Architecture 1.1 Core Design Idea To solve the problems of protocol compatibility, negotiation efficiency, and dynamic adaptation in secure interconnection of nodes in heterogeneous networks, this protocol proposes a "three-layer separated negotiation architecture". Each layer has independent functions and works collaboratively through clear data flow logic, as follows: Transport Layer Discovery Protocol (TLDP): Based on standardized meta-protocol identifiers, it actively initiates bidirectional protocol capability detection between nodes. It can comprehensively collect core information such as the protocol types, version ranges, cipher suite lists, and extended function configurations supported by the target node, forming a structured capability dataset, providing complete and accurate basic data support for the subsequent negotiation process.

[0009] Unified Secure Session Model (USSM): To address the heterogeneity of security parameters across different security protocols (such as TLS, IPsec, and WireGuard), a generalized abstract framework is constructed. Key parameters of various protocols, such as key exchange algorithms, cipher suites, authentication methods, and session lifecycles, are uniformly mapped to standardized descriptors containing core fields such as protocol identifier, algorithm identifier, authentication mode encoding, and session timeout threshold. This enables unified representation and cross-protocol mutual recognition of security parameters across different protocols.

[0010] The Policy-Driven Negotiation Engine (PDNE) integrates game theory's multi-objective decision-making logic with a real-time risk assessment mechanism. It uses node capability data collected by TLDP and standardized by USSM as its core input, and combines network bandwidth, latency, threat level, and device resource status such as CPU and memory to establish a dynamic selection model. Through multi-dimensional index trade-offs, it achieves intelligent decision-making on the optimal security protocol and parameter combination.

[0011] The three-layer architecture fully realizes the cross-protocol security negotiation process through the orderly linkage of "TLDP acquisition → USSM standardization → PDNE decision".

[0012] 1.2 Protocol Stack Position This protocol is deployed between the application layer data and the existing security protocol layer, forming an independent multi-protocol security negotiation layer. Its position in the network protocol stack is as follows: This layered design does not change the underlying structure of the existing protocol stack. It interacts with the transport layer and the existing security protocol layer through standardized interfaces. The interfaces follow the TCP / UDP / QUIC transport specifications and the TLS / IPsec / WireGuard protocol interaction standards. It can be directly embedded into heterogeneous network environments for deployment without modifying existing network devices and protocol stacks.

[0013] 2. Protocol Implementation Process 2.1 Phase 1: Capability Discovery and Exchange The core purpose of capability discovery and exchange is to achieve bidirectional interoperability of protocol capabilities between the two communicating nodes, while ensuring the security and integrity of the interactive data, and providing accurate and complete basic data for subsequent negotiation. The specific process and related definitions are as follows: The communication initiator (Node A) first collects the security protocols and parameters it supports through its local protocol stack, constructs a "protocol capability description frame (CAP_FRAME)," and actively sends the frame to the communication responder (Node B); after receiving it, Node B collects its own capabilities in the same format and feeds back the corresponding protocol capability description frame, completing the bidirectional capability interaction.

[0014] The structured definition of the protocol capability description frame is as follows: CAP_FRAME := {version: uint8, / / This protocol version number, used to ensure frame format compatibility (e.g., 0x01 corresponds to version V1.0) nonce:

[16] byte, / / Random number, generated by the node's local cryptographically secure random number generator (CSPRNG), used to prevent replay attacks protocol_list: [ / / All security protocols supported by the node and their corresponding parameter sets {protocol_id: uint16, / / Unique identifier of the protocol (e.g., 0x01=TLS, 0x02=IPsec, 0x0F=DTLS) version_range: [2]uint16, / / Supported protocol version range ([lowest version number, highest version number], e.g., [0x0304, 0x0308] corresponds to TLS 1.3) cipher_suites: [][2]byte, / / List of supported cipher suites (each group is a unique identifier assigned to the IANA standard) extensions: []Extension / / Supported protocol extension functions (such as key update, session reuse, certificate compression, etc.)}],policy_hash:

[32] byte / / Security policy Merkle root hash value, used to verify policy integrity} After receiving the protocol capability description frame from the other party, the node first performs frame legality and integrity verification: verifying that the nonce has not been reused (by checking the recent nonce cache pool maintained locally), and then comparing the Merkle root generated by the local security policy with the received policy_hash to confirm that the policy has not been tampered with. After the verification is passed, the security strength of each protocol is quantitatively evaluated.

[0015] The assessment is achieved through a security strength quantification function, the specific formula of which is as follows: Each parameter is clearly defined and quantifiable, as detailed below: :protocol The security strength quantification score ranges from [0,1], with a higher score indicating higher security strength. The weight coefficient of the k-th cryptographic algorithm is pre-configured according to the algorithm's security level (e.g., AES-256-GCM=1.0, ChaCha20=0.95, AES-128-CBC=0.8, 3DES=0.5). :protocol The support function for the k-th cryptographic algorithm returns 1 if it fully supports the algorithm (meets all core functional requirements), 0.5 if it partially supports the algorithm (only basic functions are met, and advanced features are not supported, such as only supporting the 128-bit IV mode of AES-256-GCM and not supporting the 256-bit IV mode), and 0 if it does not support the algorithm at all. The theoretical time to break the k-th cryptographic algorithm (in MIPS years), based on the size of the algorithm's key space (e.g., the key space of AES-256 is...). Based on the current mainstream computing power level (such as 100 PFlops), the time required for a brute-force attack is deduced. The historical number of times vulnerabilities of the k-th cryptographic algorithm have been exposed is taken from statistics from public vulnerability databases such as CVE and NVD. : The lifetime (in months) of the k-th cryptographic algorithm, calculated from the date of its public deployment to the present time.

[0016] Through the above frame structure definition, reception verification logic and quantization function, the two communicating parties can securely, comprehensively and objectively obtain and evaluate each other's protocol capabilities, providing standardized and highly reliable data support for subsequent policy negotiation.

[0017] 2.2 Phase Two: Strategy Negotiation The core objective of strategy negotiation is to select the optimal protocol and parameter combination that balances security, efficiency, and resource consumption, based on the capability data and security strength assessment results of both parties obtained in Phase One. Specifically, this phase employs an improved Vickrey-Clarke-Groves mechanism to construct a multi-objective optimization model. The optimal protocol is determined by maximizing the comprehensive utility function, while simultaneously selecting Top-N candidate protocols (providing input for subsequent parallel handshakes). The function definition is as follows: Each parameter is clearly defined, quantifiable, and has a clear value logic. The specific explanation is as follows: U: Protocol overall utility score, with a value range of [0, +∞). The higher the score, the better the protocol. , , : Environmental adaptive weight coefficients, summing to 1, dynamically adjusted based on the network scenario (e.g., in security-first scenarios). =0.6, =0.2, =0.2; in resource-constrained scenarios =0.3, =0.3, =0.4); S: Protocol security score, which is the score calculated in Phase 1 using the security strength quantification function. Value; E: Protocol efficiency factor, ranging from [0,1], reflects handshake efficiency. The actual handshake time for the protocol (unit: ms). The preset maximum acceptable handshake time (configured according to network type, such as LAN) =100ms, Wide Area Network =500ms); C: Protocol resource overhead coefficient, with a value range of [0,1], and m is the number of core resource types required for protocol operation (e.g., if there are two types of core resources, such as CPU and memory, then m=2). CPU utilization (%) for protocol encryption operations. The memory footprint (MB) for protocol session caching. The maximum available threshold for the resources corresponding to the node (e.g., maximum CPU utilization of 80%, maximum available memory cache of 100MB); N: the number of candidate protocols, the value of which is dynamically configured according to the node's resource capabilities (e.g., N=5 for high-performance servers, N=2 for restricted IoT devices) to ensure that concurrent handshakes do not exceed the node's resource carrying capacity.

[0018] The above optimization model can achieve a dynamic trade-off between security, efficiency, and resource consumption, and select the optimal protocol and Top-N candidate protocols that are suitable for the current network environment and device status.

[0019] 2.3 Phase 3: Parallel Handshake and Verification To improve the success rate of protocol negotiation and handshake efficiency, this phase adopts a multi-protocol concurrent trial mechanism. Based on the Top-N candidate protocols selected in Phase 2, the parallel handshake process is initiated. The specific steps are as follows: (1) The initiator generates a corresponding handshake initialization packet for each candidate protocol based on the Top-N candidate protocols determined in Phase 2. The packet carries unique identification information (including protocol_id consistent with the phase and session identifier generated by concatenating Nonce_A and the initiator's node ID). Then, all handshake initialization packets are sent to the responder simultaneously. (2) After receiving all handshake initialization packets, the responder accurately distinguishes the connection requests of different candidate protocols by using the protocol_id and session identifier carried in the packet. Based on its own protocol capabilities and comprehensive utility evaluation results, the responder selects the optimal protocol to send a handshake response packet and asynchronously terminates the connection requests of other candidate protocols, releasing relevant resources. (3) After both parties complete the handshake process based on the optimal protocol and establish a secure channel, they immediately perform protocol consistency verification. The verification logic is as follows: in, , These are the optimal protocol and parameter configuration sets (including protocol type, version, cipher suite, and extended functions) determined by the initiator and the responder, respectively. , The random number is used for the Phase 1 interaction; if the verification is successful, the secure channel becomes effective; if the verification fails, the Phase 2 policy negotiation is retried.

[0020] This mechanism reduces handshake waiting time through concurrent probing, avoids connection confusion through explicit packet identification, ensures the accuracy of protocol execution through consistency verification, and avoids connection failures caused by protocol mismatch.

[0021] 2.4 Phase Four: Dynamic Protocol Switching To address changes in the network environment (such as link quality degradation or escalating security threats), this protocol supports dynamic protocol switching during session duration to ensure communication continuity and security. The specific implementation is as follows: A switching trigger function is defined to determine whether a protocol switch is necessary. The function expression is as follows: The definitions and value retrieval logic of each parameter are as follows: : Switch trigger flag, 1 indicates that switching is required, 0 indicates that switching is not required; : Packet loss rate per unit time (% / s) To count the number of lost data packets within the statistical period. The statistical period is fixed at 10 seconds to ensure evaluation stability. : Preset packet loss rate threshold (% / s), configured according to business requirements (e.g., real-time services) =1% / s, non-real-time business =5% / s); The real-time threat score of the current network, with a value range of [0,10], is calculated based on data such as attack type (e.g., brute force, man-in-the-middle attack, vulnerability exploitation), attack frequency (number of attack attempts per unit time), and attack source credibility (0-1 credibility coefficient marked by the intelligence platform) pushed by the threat intelligence platform, and is weighted by preset weights (0.4 for attack type, 0.3 for attack frequency, and 0.3 for attack source credibility). : Preset threat scoring thresholds, such as =6 (A score of ≥6 indicates high risk and requires protocol switching).

[0022] when When =1, the protocol switching process is triggered: both parties negotiate through the established secure channel, and select the suboptimal protocol from the candidate protocol list as the new working protocol based on the strategy negotiation logic of Phase 2; after the negotiation is completed, the initiator sends a protocol switching notification (carrying the new protocol identifier and session state migration parameters), and both parties switch to the new protocol synchronously and migrate the session state (including the current key, session sequence number, unfinished data cache, etc.). During the switching process, the transmission data is temporarily stored through a caching mechanism to ensure that the data transmission is not interrupted; after the switching is completed, the new protocol takes effect, and the original protocol is retained as a backup protocol for subsequent switching as needed.

[0023] Beneficial Effects: The beneficial effects of this invention are as follows: 1. Solving the problem of heterogeneous protocol compatibility: It supports cross-layer negotiation of multiple protocols such as TLS, IPsec, and DTLS, enabling seamless interconnection of heterogeneous nodes such as IoT restricted devices and servers without the need for a full network upgrade, thus reducing forward compatibility costs.

[0024] 2. Improve negotiation efficiency and real-time performance: By using two-way capability detection and multi-protocol parallel handshake mechanism, shorten the negotiation time for cross-protocol interconnection and adapt to the real-time service latency requirements of the power grid and other applications.

[0025] 3. Optimize security and resource balance: Based on a multi-objective decision-making model with dynamic weights, combined with real-time risk assessment and device resource status, the optimal protocol and cryptographic suite are dynamically selected to balance security strength and resource consumption.

[0026] 4. Ensure communication continuity and security: Support dynamic switching of session protocols to cope with scenarios such as link fluctuations and security threats, and avoid data loss through state transition and caching mechanisms to meet high security requirements. Attached Figure Description

[0027] Figure 1 is a schematic diagram of the protocol flow described in this invention. The figure illustrates the implementation process of the node secure interconnection negotiation protocol that is compatible with multiple protocol suites. Detailed Implementation

[0028] The present invention will be further described below with reference to specific implementation methods: 1. Embodiment This embodiment takes the heterogeneous network environment of smart grid as the application scenario, and describes in detail the specific implementation process of the node security interconnection negotiation protocol compatible with multiple protocol suites, and verifies the feasibility and adaptability of the protocol in the scenario of heterogeneous grid equipment, high security requirements and strict real-time requirements.

[0029] 1.1 Grid Scenarios and Equipment Configuration Smart grid networks contain various heterogeneous nodes, each supporting significantly different security protocol stacks. Specific configurations are as follows: Initiator Node: Distribution Terminal (IoT-restricted device), deployed at the distribution station, supports DTLS 1.3 protocol, core resource configuration is 1GHz CPU and 256MB memory, supports only lightweight cipher suites (AES-128-CCM, ChaCha20-Poly1305), business requirement is real-time uploading of distribution data (latency threshold ≤300ms), security level requirement is anti-tampering and anti-replay attack; Response Node: Grid Regional Control Center Server (high-performance device), supports TLS 1.3 and IPsec protocols, core resource configuration is 3.5GHz CPU and 32GB memory, supports full cipher suites (including AES-256-GCM, SM4-GCM, etc.), business requirement is receiving and processing multi-terminal distribution data, security level requirement is compliance with Level 3 of the "Power Industry Network Security Level Protection 2.0" standard.

[0030] This protocol is deployed in the protocol stack of the aforementioned nodes, located between the application layer (power distribution data transmission protocol) and the existing security protocol layer (DTLS 1.3 / TLS 1.3 / IPsec), without requiring modification to the existing power grid equipment hardware and underlying protocol stack.

[0031] 1.2 Protocol Implementation Steps 1.2.1 Phase 1: Capability Discovery and Exchange (1) The power distribution terminal (Node A) collects its own capabilities through the local protocol stack and constructs a protocol capability description frame (CAP_FRAME): CAP_FRAME := {version: 0x01 (V1.0 version), nonce: [0x12, 0x34, ..., 0xAB] (16-byte CSPRNG generates random numbers), protocol_list: [{protocol_id: 0x0F (DTLS), version_range: [0x0304, 0x0308] (DTLS 1.3 version range), cipher_suites: [[0x00, 0x9C] (AES-128-CCM), [0x00, 0xCC] (ChaCha20-Poly1305)], extensions: [key update, session reuse]}], policy_hash: [0x5F, [0x7A, ..., 0x9D] (Power grid security policy Merkel root hash)} Node A sends the frame to the control center server (Node B) via UDP link.

[0032] (2) After receiving the data, Node B first performs verification: confirms that the random number is not repeated through the local nonce cache pool, and then compares the Merkle root of the local power grid security policy with the policy_hash. After the verification is successful, it returns its own CAP_FRAME (including TLS 1.3, IPsec protocol capabilities and corresponding parameters).

[0033] (3) Both parties evaluate the security strength of each other's protocols based on the security strength quantification function: Taking the DTLS protocol of node A as an example, calculate the security strength score corresponding to the AES-128-CCM algorithm. : (AES-128-CCM) = 0.85 (DTLS fully supports this algorithm) = 1; (AES-128 brute-force attack time) = 1.07 × 10 24 MIPS year, ; (Number of historical vulnerabilities) = 2. (Survival period) = 120 months; calculated as follows: = (0.85×1) / 81×(1 - 2 / 120)≈0.0103×0.983≈0.0101 (Meets the safety requirements for lightweight power grid equipment).

[0034] 1.2.2 Phase Two: Strategy Negotiation (1) Based on the capability data of both parties, Node B constructs a comprehensive utility function using an improved Vickrey-Clarke-Groves mechanism and configures environmental adaptive weights: prioritizing safety in the power grid scenario. =0.6, =0.3, =0.1.

[0035] (2) Calculation of each parameter: S: DTLS protocol of node A =0.0101, Node B's TLS 1.3 protocol =0.0125, IPsec protocol =0.0118; E: DTLS handshake time =80ms =300ms (real-time power grid service threshold), E=1-80 / 300≈0.733; TLS 1.3 handshake time 120ms, E=1-120 / 300=0.6; C: Node A's DTLS protocol CPU utilization = 15%, memory usage = 8MB, (CPU=80%, Memory=64MB), C=(15 / 80)+(8 / 64)=0.1875+0.125=0.3125.

[0036] (3) Calculation of comprehensive utility: DTLS protocol U=0.6×0.0101 + 0.3×0.733 - 0.1×0.3125≈0.0061 + 0.2199 -0.0313≈0.1947; TLS 1.3 protocol U=0.6×0.0125 + 0.3×0.6 - 0.1×0.4≈0.0075 + 0.18 - 0.04≈0.1475; The optimal protocol is DTLS 1.3, and the Top-N candidate protocols N=1 (Node A is a restricted device with a low resource carrying capacity).

[0037] 1.2.3 Phase 3: Parallel Handshake and Verification (1) Node A (distribution terminal) generates a DTLS handshake initialization packet based on the Top-1 candidate protocol. The packet carries protocol_id=0x0F and session identifier= +Node A device ID (unique code for power grid equipment) is sent to Node B via UDP.

[0038] (2) After receiving the protocol, Node B confirms the protocol type with the protocol_id and the session identifier, sends a DTLS handshake response packet, and the two parties complete the handshake and establish a secure channel.

[0039] (3) Protocol consistency verification: Node A computes ( (Including DTLS1.3+AES-128-CCM), node B computation If the hash values ​​of both parties match, the verification is successful, the secure channel is activated, and the power distribution data begins to be transmitted in encrypted form.

[0040] 1.2.4 Phase Four: Dynamic Switching Protocol (1) During operation, Node A monitors the network status in real time: [Settings are missing from the original text] =2% / s (the maximum packet loss rate allowed for power grid services). =6 (threat score threshold).

[0041] (2) When the distribution network experiences link fluctuations, within a 10-second statistical period =3、 =10s, The threat intelligence platform reports a current network threat score of 4.5 (<6). =0, keeping the DTLS protocol unchanged.

[0042] (3) If a brute-force attack is subsequently detected, the threat score rises to 7.2 > 6. =1: Both parties negotiate through the existing secure channel to switch to the IPsec protocol supported by Node B (the second-best option in the candidate protocol list), migrate the session key, cached untransmitted power distribution data, etc. During the switchover, the caching mechanism ensures that the data is not lost. After the switchover is completed, the data continues to be transmitted through the IPsec protocol, which meets the power grid security level requirements.

[0043] 1.3 Implementation Results In this embodiment, the protocol successfully achieves secure interconnection between heterogeneous nodes in the smart grid (restricted distribution terminals and high-performance control center servers), solving the compatibility issues caused by heterogeneity in traditional protocols; the negotiation time is only 89ms, far below the grid service delay threshold (300ms), meeting real-time requirements; through dynamic security assessment and switching mechanisms, the security and continuity of distribution data transmission are guaranteed, fully adapting to the technical requirements of the grid scenario.

[0044] The embodiments of the present invention are not limited to the heterogeneous network scenario of smart grids. The target security protocol, cryptographic suite and security parameters can be adjusted according to actual scenarios such as the Internet of Things and the Industrial Internet. The three-layer separate negotiation architecture is used to adapt to the requirements, and such improvements all fall within the scope of protection.

Claims

1. A node secure interconnection negotiation protocol compatible with multiple protocol suites, characterized in that, The architecture employs a "three-layer decoupled negotiation architecture," achieving secure cross-protocol interconnection through four phases. Specifically, the three-layer decoupled negotiation architecture includes the Transport Layer Discovery Protocol (TLDP), the Unified Secure Session Model (USSM), and the Policy-Driven Negotiation Engine (PDNE). The three layers complete cross-protocol secure negotiation through the orderly linkage of "TLDP acquisition → USSM standardization → PDNE decision-making." The four phases are capability discovery and exchange, policy negotiation, parallel handshake and verification, and dynamic protocol switching. Each phase achieves secure and efficient protocol interconnection through standardized data interaction and quantitative decision-making logic.

2. The protocol according to claim 1, characterized in that, The Transport Layer Discovery Protocol (TLDP) is based on standardized meta-protocol identifiers and actively initiates bidirectional protocol capability detection between nodes. It collects core information such as the target node's protocol type, version range, cipher suite list, and extended function configuration to form a structured capability dataset.

3. The protocol according to claim 1, characterized in that, The Unified Secure Session Model (USSM) constructs a generalized abstract framework that maps key parameters of different security protocols such as TLS, IPsec, and WireGuard, including key exchange algorithms, cipher suites, authentication methods, and session lifecycles, into standardized descriptors containing protocol identifiers, algorithm identifiers, authentication mode encodings, and session timeout thresholds, thereby enabling cross-protocol parameter mutual recognition.

4. The protocol according to claim 1, characterized in that, The Policy-Driven Negotiation Engine (PDNE) integrates game theory multi-objective decision-making logic with a real-time risk assessment mechanism. It takes node capability data collected by TLDP and standardized by USSM as input, and combines network bandwidth, latency, threat level and device CPU and memory resource status to establish a dynamic selection model and output the optimal security protocol and parameter combination.

5. The protocol according to claim 1, characterized in that, The protocol is deployed between the application layer data and the existing security protocol layer, forming an independent multi-protocol security negotiation layer. It interacts with the transport layer and the existing security protocol layer through standardized interfaces in accordance with the TCP / UDP / QUIC transmission specifications and the TLS / IPsec / WireGuard protocol interaction standards, without the need to modify existing network equipment and protocol stacks.

6. The protocol according to claim 1, characterized in that, The capability discovery and exchange phase achieves bidirectional capability interaction through a "protocol capability description frame (CAP_FRAME)". The CAP_FRAME includes a version number, a 16-byte nonce, a list of protocol capabilities, and a security policy Merkle root hash (policy_hash). The receiver verifies the legitimacy and integrity of the frame by comparing the nonce cache pool with the policy_hash, and evaluates the protocol security strength through a security strength quantification function.

7. The protocol according to claim 6, characterized in that, The security strength quantification function is: ,in For the agreement The security strength score, These are the weighting coefficients for the cryptographic algorithm. Let the protocol support function for the algorithm be... For the time required to solve the algorithm theory, This represents the number of historical vulnerabilities in the algorithm. This refers to the algorithm's lifetime.

8. The protocol according to claim 1, characterized in that, The strategy negotiation phase employs an improved Vickrey-Clarke-Groves mechanism to construct a multi-objective optimization model, which maximizes the overall utility function. Filtering the optimal protocol and Top-N candidate protocols, among which For protocol efficiency factor, This is the resource cost coefficient. 、 、 These are the environmental adaptive weighting coefficients, and their sum is 1.

9. The protocol according to claim 1, characterized in that, The parallel handshake and verification phase initiates a concurrent handshake based on Top-N candidate protocols. The handshake initialization packet carries a session identifier concatenated with protocol_id and "Nonce + node ID". After the responder selects the optimal protocol to complete the handshake, it then... Perform protocol consistency verification, where 、 This is the optimal protocol and parameter configuration set for both parties.

10. The protocol according to claim 1, characterized in that, The dynamic switching protocol phase uses a switching trigger function. To determine whether a switchover is needed, the packet loss rate per unit time is used. $Exceeds the threshold or network threat score Exceeding the threshold hour, =1 triggers both parties to negotiate a switch to a suboptimal protocol through a secure channel, synchronously migrating session keys, sequence numbers, and incomplete data caches to ensure uninterrupted data transmission.

Images