A security check method based on a Netty architecture and related products

Abstract

This application discloses a security verification method and related products based on the Netty architecture. The method includes: responding to the IEC104 protocol decoder parsing TCP data, reading trusted verification metadata from the byte buffer container ByteBuf via pointer offset; performing trusted verification on the TCP data based on the trusted verification metadata; and, if the trusted verification is successful, transparently transmitting the TCP data to the business logic processor. In this embodiment, the trusted state processor is embedded as a core component in Netty's transport layer, performing security verification logic after protocol decoding and before business processing. This makes security verification an inherent part of the data transmission process, rather than an afterthought, thereby achieving "zero-copy" trusted state embedding and verification of IEC104 protocol messages at the transport layer, shortening the trusted verification latency.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a security verification method and related products based on the Netty architecture. Background Technology

[0002] Power monitoring systems (such as SCADA and EMS) are the core of the nation's critical information infrastructure, and their communication security is of paramount importance. Among them, power monitoring systems (especially control-related services such as relay protection, stability control, remote adjustment, and remote control) generally require millisecond or even sub-millisecond communication response times.

[0003] In related technologies, power monitoring systems typically implement trusted verification during the communication process at the application layer. Logic such as trusted measurement, identity authentication, and integrity verification is deeply coupled with real-time power control business. The verification process needs to wait for the upper-layer application data to be parsed and encapsulated before it can be executed, which brings additional computational overhead and communication delay, thus failing to meet the strong real-time requirements of power control business. Summary of the Invention

[0004] To address the aforementioned issues, this application provides a security verification method and related products based on the Netty architecture, which reduces communication latency in power monitoring systems and meets the high real-time requirements of power control services.

[0005] The embodiments of this application disclose the following technical solutions: In a first aspect, embodiments of this application provide a security verification method based on the Netty architecture, characterized in that it is applied to a trusted state processor in the transport layer of the Netty architecture, and the method includes: In response to the IEC104 protocol decoder parsing TCP data, trusted verification metadata is read from the byte buffer container ByteBuf via pointer offset; Based on trusted verification metadata, TCP data is verified for trustworthiness. If the trusted verification is successful, the TCP data will be transparently transmitted to the business logic processor.

[0006] In one possible implementation, trusted verification metadata includes device fingerprints, trusted status codes, key indexes, and hardware counters. Trusted verification includes identity whitelist verification, platform integrity verification, key freshness verification, and counter replay protection verification. Based on the trusted verification metadata, trusted verification is performed on TCP data, including: TCP data is verified using device fingerprints for identity whitelist verification, TCP data is verified for platform integrity based on trusted status codes, TCP data is verified for key freshness based on key indexes, and TCP data is verified for counter replay protection based on hardware counters.

[0007] In one possible implementation, TCP data is verified using an identity whitelist, platform integrity, key freshness, and counter anti-replay measures within the same EventLoop thread.

[0008] In one possible implementation, the EventLoop thread is an EventLoop thread that handles network I / O, and trusted verification is triggered and executed by the EventLoop thread that handles network I / O.

[0009] In one possible implementation, the method also includes: If the trusted verification fails, the TCP communication connection will be terminated.

[0010] In one possible implementation, the method also includes: In response to a ChannelReadComplete event initiated by a Netty Channel, a timestamp is requested from the hardware root of trust. A second key is generated based on the timestamp, the first key, and the sequence number of the TCP data. Send an update session key command to the Netty Channel to synchronize the second key to the TCP communication link.

[0011] In one possible implementation, the method also includes: Determine the continuity of valid bits in the frame count; The TCP communication connection is interrupted if the valid bits of the frame count change discontinuously. The TCP communication connection continues as long as the valid bits of the frame count are consecutive.

[0012] Secondly, embodiments of this application provide a security verification system based on the Netty architecture, wherein the Netty architecture transport layer includes a trusted state processor; The trusted state processor is configured to parse TCP data in response to the IEC104 protocol decoder, read trusted verification metadata from the byte buffer container ByteBuf through pointer offset; perform trusted verification on the TCP data based on the trusted verification metadata; and pass the TCP data through to the business logic processor if the trusted verification is successful.

[0013] In one possible implementation, the trusted state processor is configured to perform identity whitelist verification on TCP data based on device fingerprint, platform integrity verification on TCP data based on trusted state code, key freshness verification on TCP data based on key index, and counter anti-replay verification on TCP data based on hardware counter.

[0014] In one possible implementation, the trusted state processor is configured to perform identity whitelist verification, platform integrity verification, key freshness verification, and counter anti-replay verification on TCP data within the same EventLoop thread.

[0015] In one possible implementation, the trusted state processor is also configured to interrupt the TCP communication connection in the event of a trusted verification failure.

[0016] In one possible implementation, the trusted state processor is also configured to request a timestamp from the hardware root of trust in response to a ChannelReadComplete event initiated by the Netty Channel; generate a second key based on the timestamp, the first key, and the sequence number of the TCP data; and issue an update session key instruction to the Netty Channel to synchronize the second key to the TCP communication link.

[0017] In one possible implementation, the trusted state processor is also configured to determine the continuity of the valid frame count bits; if the valid frame count bits change discontinuously, interrupt the TCP communication connection; and if the valid frame count bits are continuous, continue the TCP communication connection.

[0018] To reduce communication latency in power monitoring systems and meet the high real-time requirements of power control services, this application provides a security verification method based on the Netty architecture. The method is characterized by a trusted state processor applied in the Netty architecture's transport layer. The method includes: responding to the IEC104 protocol decoder parsing TCP data by reading trusted verification metadata from the byte buffer container ByteBuf via pointer offset; performing trusted verification on the TCP data based on the trusted verification metadata; and, if the trusted verification is successful, transparently transmitting the TCP data to the business logic processor. In this application embodiment, a dedicated "trusted state processor" is embedded as a core component in the transport layer of Netty's ChannelPipeline. Security verification logic is performed after protocol decoding and before business processing, making security verification an inherent part of the data transmission process rather than an afterthought. This achieves "zero-copy" trusted state embedding and verification of IEC104 protocol messages at the transport layer, shortening the trusted verification latency. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 A schematic diagram of a Netty architecture provided for an embodiment of this application; Figure 2 A flowchart illustrating a security verification method based on the Netty architecture provided in this application embodiment; Figure 3 A schematic diagram of another Netty architecture provided in an embodiment of this application; Figure 4 A schematic diagram illustrating the interaction between a hardware root of trust, a trusted state processor, and a Netty channel, provided in an embodiment of this application; Figure 5 A schematic diagram illustrating the interaction between a hardware root of trust, a trusted state processor, and a Netty channel, provided for an embodiment of this application. Figure 6 A schematic diagram of a system deployment architecture provided in an embodiment of this application; Figure 7 This is a schematic diagram of a control device provided in an embodiment of this application. Detailed Implementation

[0021] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0022] The terms "first" and "second," etc., used in the specification and claims of this application are used to distinguish different objects, not to describe a specific order of objects. For example, "first operation instruction" and "second operation instruction," etc., are used to distinguish different operation instructions, not to describe a specific order of operation instructions.

[0023] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0024] In the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more, for example, multiple processing units means two or more processing units, multiple elements means two or more elements, etc.

[0025] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0026] Netty is an open-source Java network framework developed and provided by JBoss. It is currently an independent project on GitHub, also known as Netty in other languages. Based on an asynchronous event-driven model, this framework supports the rapid development of high-performance, highly reliable network server and client programs. It uses NIO technology to implement Socket service development under the TCP / UDP protocol and can handle multiple communication protocols such as FTP, SMTP, and HTTP.

[0027] To facilitate understanding of the technical solution of this application, the following will be combined with... Figure 1 The Netty architecture described in the embodiments of this application will be introduced accordingly.

[0028] like Figure 1 As shown, the Netty architecture includes: a TCP decoder 100, an IEC104 protocol decoder 200, a trusted state processor 300, a business logic processor 400, an IEC104 protocol encoder 500, and a TCP encoder 600. Among these, the TCP decoder 100, IEC104 protocol decoder 200, and trusted state processor 300 reside at the transport layer, i.e. Figure 1 The dashed box portion; the business logic processor 400 is located in the application layer.

[0029] When the Netty architecture described above is applied to a server-side device, the network input can be the output of the client-side device, and the network output can be the output of the server-side device; when the Netty architecture described above is applied to a client-side device, the network input can be the output of the server-side device, and the network output can be the output of the client-side device.

[0030] TCP decoder 100 is configured to handle TCP packet splitting and reassembly.

[0031] The IEC104 protocol decoder 200 is configured to parse IEC104 protocol messages and extract service data.

[0032] Trusted State Processor 300 is configured to perform trusted verification of TCP data.

[0033] The business logic processor 400 is configured to accept securely verified data and perform business-level processing.

[0034] The IEC104 protocol encoder 500 is configured to repackage processed data into the IEC104 protocol format.

[0035] The TCP encoder 600 is configured to encapsulate protocol data into TCP packets.

[0036] It should be noted that the descriptions of the actions performed by the TCP decoder 100, IEC104 protocol decoder 200, trusted state processor 300, business logic processor 400, IEC104 protocol encoder 500, and TCP encoder 600 are merely exemplary and are not specifically limited in this application.

[0037] Based on the Netty architecture described above, this application provides a security verification method based on the Netty architecture, the corresponding flowchart of which can be found in [link to flowchart]. Figure 2 .

[0038] like Figure 1 As shown, the security verification method based on the Netty architecture includes the following steps: S1000: The trusted state processor responds to the IEC104 protocol decoder by parsing TCP data and reads trusted verification metadata from the byte buffer container ByteBuf via pointer offset.

[0039] Among them, TCP data is the output data of the TCP decoder.

[0040] After the TCP decoder performs packet splitting and reassembly on the original TCP packets and restores the data conforming to the IEC104 protocol format, the trusted state processor pointer offset reads trusted verification metadata from the byte buffer container ByteBuf.

[0041] In this embodiment of the application, the specific form of trusted verification metadata is not limited. For example, trusted verification metadata may include device fingerprint, trusted status code, key index and hardware counter.

[0042] For example, a device identifier can be an 8-byte long integer / hash value that uniquely identifies the device.

[0043] For example, a trusted status code can be a 2-byte short integer that identifies the integrity status of a device / platform, such as 0 = intact, 1 = tampered with, and 2 = unknown.

[0044] For example, the key index can be a 4-byte integer that identifies the key version / batch currently in use.

[0045] For example, the hardware counter can be an 8-byte long integer, an incrementing counter on the device side, incrementing by 1 for each message sent.

[0046] S2000: The Trusted State Processor performs trusted verification on TCP data based on trusted verification metadata.

[0047] Trusted verification can include identity whitelist verification, platform integrity verification, key freshness verification, and counter anti-replay verification.

[0048] TCP data is verified using device fingerprints for identity whitelist verification, TCP data is verified for platform integrity based on trusted status codes, TCP data is verified for key freshness based on key indexes, and TCP data is verified for counter replay protection based on hardware counters.

[0049] For example, for identity whitelist verification, the trusted state processor pre-stores the fingerprints of legitimate devices in a local memory whitelist (such as a ConcurrentHashMap).<Long,Boolean> The trusted state processor directly uses the device fingerprint read from the ByteBuf as the key to query the whitelist. In this embodiment, the trusted state processor only performs a hash comparison to determine whether the device exists, thus completing the identity whitelist verification.

[0050] For example, for platform integrity verification, a preset set of valid trusted status codes (e.g., only allowing 0) is used. The trusted status processor compares the trusted status code read from the ByteBuf with the preset value as an integer, thus achieving platform integrity verification. In this embodiment, the trusted status processor does not need to parse the meaning of the status code; it only needs to determine whether it is within the valid value range to achieve platform integrity verification.

[0051] For example, for key freshness verification, the dynamic key manager maintains a "latest valid key index" (an integer variable in memory); the trusted state processor compares the key index read from the ByteBuf with the "latest index" as an integer. In this embodiment, the trusted state processor only determines whether it is the currently valid index (if the index = the latest index, then it is fresh; otherwise, it is an expired key).

[0052] For example, for counter-based replay protection verification, a "last received counter value" (in memory, AtomicLong) is maintained for each legitimate device; the trusted state processor compares the hardware counter read from the ByteBuf with the "last value" as an integer. In this embodiment, the trusted state processor only determines "current counter > last counter" (to prevent replay attacks, the counter of a replay message will be ≤ last value).

[0053] In the above example of trusted verification, all comparisons are integer / hash pairs, with no public key operations, resulting in a relatively short verification time and thus reducing the time required for trusted verification.

[0054] It should be noted that in this embodiment of the application, TCP data can be verified for identity whitelist, platform integrity, key freshness, and counter anti-replay verification within the same EventLoop thread.

[0055] S3000: The trusted state processor will pass TCP data to the business logic processor if the trusted verification is successful.

[0056] This application inserts a trusted state processor into the ChannelPipeline, the core channel for processing network data flows within the Netty framework. This processor is located after protocol decoding and before business logic processing, enabling security verification to be performed early in the data flow, achieving "security decentralization." This makes security verification an inherent part of the data transmission process, rather than an afterthought, thus achieving "zero-copy" trusted state embedding and verification of IEC104 protocol messages at the transport layer, reducing trusted verification latency.

[0057] In addition, the trusted state processor interrupts the TCP communication connection if the trusted verification fails.

[0058] For example, a trusted state handler can close the current ChannelHandlerContext using ctx.close(), which in turn closes the node where the current handler context resides.

[0059] In this embodiment, Netty's native ChannelFuture mechanism is used to immediately interrupt the session at the transport layer when verification fails, and to link the SDN controller to achieve network isolation, thus achieving microsecond-level rapid threat response.

[0060] In this embodiment, the execution mechanism is integrated, meaning that the lightweight dynamic measurement task (trusted verification operation) is directly triggered and executed by the Netty EventLoop thread that handles network I / O. This avoids the overhead of cross-thread communication, making security verification a natural part of the communication process rather than an additional operation. The lightweight dynamic measurement task (trusted verification operation) is directly triggered and executed by the Netty EventLoop thread without cross-thread submission, eliminating thread switching and queue waiting.

[0061] The triggering operation can be implemented through a three-level triggering model: connection activation triggering submits the first measurement to the current EventLoop through channelActive, and the trusted state is ready before business processing; time period triggering is scheduled by EventLoop, and integrity checks are performed in the same thread after the expiration, without an independent timer thread; message frequency triggering adds the measurement task to the tail of the EventLoop queue for every N messages, without blocking channelRead propagation, and is completed during I / O intervals.

[0062] In addition, the embodiments of this application can also optimize and upgrade the performance of the original EventLoop thread model. The core is to "strip" the time-consuming TPM hardware I / O operations from the EventLoop thread, retain only the lightweight asynchronous request submission and callback processing, and reduce the frequency of hardware I / O through caching, so as to ensure the high throughput of the EventLoop thread without sacrificing the integrity of security verification.

[0063] In addition, this application embodiment can also optimize the task scheduling of the Netty EventLoop thread model with fine-grained precision. The core is to ensure that the I / O and security verification of IEC104 messages (core real-time tasks) are not blocked by non-core tasks such as measurement and callbacks through "high-priority / low-priority task isolation + consumption rule restrictions + backlog circuit breaking", thus thoroughly guaranteeing the real-time requirements of industrial scenarios. High-priority tasks are consumed first in each round, and a maximum of one low-priority task is consumed per round; when the queue backlog exceeds the limit, the circuit breaking occurs, and old tasks are discarded to ensure I / O real-time performance.

[0064] In this embodiment, a response mechanism is integrated. When trusted verification fails, the network session is immediately interrupted using Netty's native ChannelFuture mechanism. The response action is completed at the transport layer without needing to be reported to the service layer, thus achieving a fast, secure response at the microsecond level. When the trusted state processor completes verification and determines failure, this application does not throw an exception or report to the service layer. Instead, it directly calls Netty's native ChannelHandlerContext.close() method, using the ChannelFuture mechanism to complete connection release and resource reclamation within the same EventLoop Tick.

[0065] The three-layer implementation of the immediate response is as follows: Zero-exception fast path: Compared to traditional solutions where verification failure requires constructing a SecurityException and throwing it layer by layer, which is then caught by the business Handler before closing the connection, involving exception object construction, stack padding, and exception handling chaining, this application completely avoids the exception mechanism. Verification failure directly calls ctx.close(), resulting in no exception overhead. Synchronous closing and resource reclamation: ctx.close() returns a ChannelFuture, and this invention actively listens to this Future and binds a resource cleanup callback. All operations are executed serially in the same EventLoop thread that initiates the closure, eliminating the need for cross-thread waiting and ensuring deterministic latency in connection release; Transport layer alarm linkage: While closing the connection, the ChannelFuture callback mechanism triggers writeAndFlush to send a lightweight alarm message to the network management system. This operation reuses the current EventLoop thread, without creating additional threads or task queues.

[0066] In this embodiment, the failure response is completely decoupled from the business layer; that is, verification failure messages are never passed to the downstream business handler, and the business layer is completely unaware of security events. After the trusted state processor completes verification in the channelRead method, if it determines that the verification has failed, it directly terminates the propagation.

[0067] In long-connection power monitoring scenarios, if TLS sessions are not forcibly rebuilt periodically, their session keys remain unchanged for a long time and lack dynamic key rotation capabilities. Attackers can then launch replay attacks once they capture valid packets. Therefore, this application provides an alternative Netty architecture, the schematic of which can be found in the following diagram. Figure 3 .

[0068] like Figure 3 As shown, the Netty architecture includes: a TCP decoder 100, an IEC104 protocol decoder 200, a trusted state processor 300, a business logic processor 400, an IEC104 protocol encoder 500, a TCP encoder 600, and a hardware root of trust 700. Among these, the TCP decoder 100, IEC104 protocol decoder 200, and trusted state processor 300 reside at the transport layer, i.e. Figure 3 The dashed box portion; the business logic processor 400 is located in the application layer.

[0069] Among them, the hardware root of trust (RoT) is an immutable and secure trust starting point embedded in the hardware, providing underlying trust protection for the entire computing platform and serving as the core cornerstone of trusted computing.

[0070] In this embodiment, the hardware root of trust and the trusted state processor use TPM or national cryptographic HSM to generate keys and issue certificates, and drive the rotation of the dynamic key chain based on the reliable timestamp of the root of trust, thus ensuring the immutability and high reliability of the secure operation.

[0071] The following will combine Figure 4 This section introduces the interaction between the hardware root of trust, the trusted state processor, and the Netty channel.

[0072] like Figure 4 As shown, the interaction between the hardware root of trust, the trusted state processor, and the Netty channel includes the following steps: S21: The Netty channel sends a ChannelReadComplete event (message reading completed) to the trusted state processor, triggering a polling count check.

[0073] For example, after completing the reading of a batch of messages, the Netty channel sends an event to the dynamic key manager in the trusted state processor as a basis for counting key rotations.

[0074] S22: The trusted state processor sends a request to the hardware root of trust to obtain the timestamp.

[0075] In this embodiment, the trusted state processor sends a request to the hardware root of trust to obtain a timestamp, that is, it requests an "entropy source" (timestamp) from the hardware root of trust to generate a new key, thereby ensuring the unpredictability of the new key.

[0076] In addition to timestamps, the aforementioned "entropy source" can also include derived parameters. These derived parameters are typically random or semi-random data (such as hardware counters, device fingerprints, and session IDs) strongly bound to device state and session context. Combining derived parameters with timestamps exponentially increases the complexity of the entropy source, making it impossible for attackers to predict the key solely based on time information, thus significantly improving the key's resistance to brute-force attacks.

[0077] S23: The hardware trusted root returns a timestamp to the trusted state processor.

[0078] S24: The trusted state processor generates a new key based on the timestamp returned by the hardware root of trust.

[0079] For example, the new key = SM3(old key||timestamp||sequence number mod10). Based on the old key, timestamp, and message sequence number (mod10), a new SM4 session key is generated using the SM3 hash algorithm, making the new key strongly correlated with time and timely; the new key is bound to the message sequence, providing a basis for subsequent replay protection.

[0080] When the hardware root of trust returns derived parameters to the trusted state processor, the new key = (old key || timestamp || derived parameters || sequence number mod 10). This exponentially increases the complexity of the new key, making it impossible for attackers to predict the key based solely on time information, thus significantly improving the key's resistance to brute-force attacks.

[0081] S25: The trusted state processor sends a new key to the Netty channel.

[0082] In this embodiment, the newly generated SM4 session key is synchronized to the Netty communication channel, and subsequent messages will be encrypted / decrypted using the new key.

[0083] It should be understood that the rotation period of the new key is not specifically limited in the embodiments of this application, for example, once every 10 messages.

[0084] In this embodiment, the entire security system (identity authentication, key management, and dynamic measurement) is built upon a hardware root of trust. Leveraging the immutability and high reliability of the hardware root of trust, a dynamic SM4-GCM key chain is constructed. Based on the immutability of the hardware root of trust, the root key is permanently embedded within the TPM. Utilizing its highly reliable hardware counter and PCR value, a dynamic session key is derived iteratively through SM3, driving SM4-GCM to change the key for each message. The key chain is bound to the platform state and isolated from the channel, achieving hardware-level forward security and automated switching, thus defending against replay attacks at their source.

[0085] In addition to the key rotation steps (S21-S25) described above, the interaction between the hardware root of trust, the trusted state processor, and the Netty channel may also include initial key negotiation and continuity verification steps, see [link to relevant documentation]. Figure 5 : S11: The hardware root of trust generates an asymmetric key pair SM2 and sends the asymmetric key pair SM2 to the trusted state processor.

[0086] In this embodiment, an asymmetric key pair SM2 is generated by a hardware trusted root as the root trust basis for subsequent key negotiation, ensuring the security of the root key.

[0087] S12: The trusted state processor initiates SM2 key negotiation to the Netty channel.

[0088] The trusted state processor uses the SM2 key pair for secure negotiation, the hardware trusted root performs cryptographic operations, generates and outputs the initial SM4 session key, and sends the SM4 session key to the Netty channel.

[0089] S21: The Netty channel sends a ChannelReadComplete event (message reading completed) to the trusted state processor, triggering a polling count check.

[0090] S22: The trusted state processor sends a request to the hardware root of trust to obtain the timestamp.

[0091] S23: The hardware trusted root returns a timestamp to the trusted state processor.

[0092] S24: The trusted state processor generates a new key based on the timestamp returned by the hardware root of trust.

[0093] S25: The trusted state processor sends a new key to the Netty channel.

[0094] S31: The dynamic key manager in the trusted state processor checks whether the frame count bit is valid.

[0095] In the IEC104 secure communication architecture, the frame count valid (FCV) bit is a 1-bit protocol extension flag bit. Its core function is to control whether to perform continuity and anti-replay checks on the frame continuous value (FC continuous value) in the message.

[0096] In this embodiment of the application, by verifying whether the FCV bit in the message is valid and whether the FCV consecutive value (frame counter) is strictly incremented, messages with incorrect format, out-of-order or obviously forged messages can be filtered out.

[0097] S32: When the valid bit of the frame count changes discontinuously, it is determined to be a replay fault.

[0098] If the dynamic key manager in the trusted state processor determines that the current packet is a replay attack, it can trigger an "interrupt session" operation, closing the connection via the Netty channel (ctx.close()) to prevent the attack from continuing.

[0099] S33: If the valid bits of the frame count are consecutive, then communication continues.

[0100] In this embodiment of the application, the message passes the basic validity check and enters the next stage, allowing continued communication.

[0101] Based on the security verification method based on the Netty architecture described in the foregoing embodiments, this application provides a security verification system based on the Netty architecture, wherein the Netty architecture transport layer includes a trusted state processor. The trusted state processor is configured to parse TCP data in response to the IEC104 protocol decoder, read trusted verification metadata from the byte buffer container ByteBuf through pointer offset; perform trusted verification on the TCP data based on the trusted verification metadata; and pass the TCP data through to the business logic processor if the trusted verification is successful.

[0102] In one possible implementation, the trusted state processor is configured to perform identity whitelist verification on TCP data based on device fingerprint, platform integrity verification on TCP data based on trusted state code, key freshness verification on TCP data based on key index, and counter anti-replay verification on TCP data based on hardware counter.

[0103] In one possible implementation, the trusted state processor is configured to perform identity whitelist verification, platform integrity verification, key freshness verification, and counter anti-replay verification on TCP data within the same EventLoop thread.

[0104] In one possible implementation, the trusted state processor is also configured to interrupt the TCP communication connection in the event of a trusted verification failure.

[0105] In one possible implementation, the trusted state processor is also configured to request a timestamp from the hardware root of trust in response to a ChannelReadComplete event initiated by the Netty Channel; generate a second key based on the timestamp, the first key, and the sequence number of the TCP data; and issue an update session key instruction to the Netty Channel to synchronize the second key to the TCP communication link.

[0106] In one possible implementation, the trusted state processor is also configured to determine the continuity of the valid frame count bits; if the valid frame count bits change discontinuously, interrupt the TCP communication connection; and if the valid frame count bits are continuous, continue the TCP communication connection.

[0107] This application inserts a trusted state processor into the ChannelPipeline, the core channel for processing network data flows within the Netty framework. This processor is located after protocol decoding and before business logic processing, enabling security verification to be performed early in the data flow, achieving "security decentralization." This makes security verification an inherent part of the data transmission process, rather than an afterthought, thus achieving "zero-copy" trusted state embedding and verification of IEC104 protocol messages at the transport layer, reducing trusted verification latency.

[0108] In addition, this application embodiment also provides a system deployment architecture, a schematic diagram of which is shown below. Figure 6 As shown.

[0109] like Figure 6 As shown, the system deployment architecture includes: server device 1000, client device 2000, power monitoring system 3000, and SDN control plane 4000.

[0110] The server device 1000 includes a hardware root of trust TMP2.0, a Netty framework instance, a trusted state processor, and a scheduling master station application module.

[0111] The trusted state processor performs trusted verification on TCP data. If the verification fails, it sends an OpenFlow command to the OpenDaylight controller in the SDN control plane.

[0112] Netty framework instances encapsulate IEC104 protocol messages on top of the TCP protocol for transmission, thereby enabling communication with power monitoring networks.

[0113] The maintainable end device 2000 includes a hardware trusted root cryptographic standard (HSM), a Netty framework instance, a trusted state processor, and a SCADA application module.

[0114] The trusted state processor performs trusted verification on TCP data. If the verification fails, it sends an OpenFlow command to the OpenDaylight controller in the SDN control plane.

[0115] Netty framework instances encapsulate IEC104 protocol messages on top of the TCP protocol for transmission, thereby enabling communication with power monitoring networks.

[0116] The power monitoring network 3000 includes two SDN switches; the SDN control plane 4000 includes an OpenDaylight controller and a flow table management module.

[0117] See Figure 7 The figure is a schematic diagram of a control device provided in an embodiment of this application.

[0118] The control device may include a memory 1011 and a processor 1012. The processor 1012 may be connected to a security verification system. Figure 7 As shown, the memory can be random access memory (RAM), flash memory, read-only memory (ROM), EPROM, non-volatile read-only memory (Electronic Programmable ROM), registers, hard disks, removable disks, etc.

[0119] The memory 1011 can store computer instructions. When the computer instructions stored in the memory 1011 are executed by the processor 1012, the processor 1012 can use them to execute a security verification method based on the Netty architecture. The memory 1011 can also store data, such as preset ranges, preset thresholds, and other information involved in the above embodiments.

[0120] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape) or a semiconductor medium (e.g., solid-state disk (SSD)).

[0121] This application also provides a readable storage medium for storing the security verification method based on the Netty architecture provided in the above embodiments. Examples include random access memory (RAM), flash memory, read-only memory (ROM), EPROM, non-volatile read-only memory (Electronic Programmable ROM), registers, hard disks, removable disks, or any other form of storage medium in the art.

[0122] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. Regarding the methods disclosed in the embodiments, since they correspond to the product embodiments disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the description of the product embodiments.

[0123] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A security verification method based on the Netty architecture, characterized in that, The trusted state processor applied in the transport layer of the Netty architecture includes the following methods: In response to the IEC104 protocol decoder parsing TCP data, trusted verification metadata is read from the byte buffer container ByteBuf via pointer offset; Based on the trusted verification metadata, the TCP data is subjected to trusted verification. If the trusted verification is successful, the TCP data is transparently transmitted to the business logic processor.

2. The security verification method according to claim 1, characterized in that, The trusted verification metadata includes device fingerprint, trusted status code, key index, and hardware counter. The trusted verification includes identity whitelist verification, platform integrity verification, key freshness verification, and counter replay protection verification. The trusted verification of the TCP data based on the trusted verification metadata includes: The TCP data is verified using the device fingerprint, the platform integrity is verified using the trusted status code, the key freshness is verified using the key index, and the counter-based replay protection is verified using the hardware counter.

3. The security verification method according to claim 2, characterized in that, Within the same EventLoop thread, the TCP data undergoes identity whitelist verification, platform integrity verification, key freshness verification, and counter replay protection verification.

4. The security verification method according to claim 3, characterized in that, The EventLoop thread is the EventLoop thread that handles network I / O, and the trusted verification is triggered and executed by the EventLoop thread that handles network I / O.

5. The security verification method according to claim 1, characterized in that, The method further includes: If the trusted verification fails, the TCP communication connection will be terminated.

6. The security verification method according to claim 1, characterized in that, The method further includes: In response to a ChannelReadComplete event initiated by a Netty Channel, a timestamp is requested from the hardware root of trust. A second key is generated based on the timestamp, the first key, and the sequence number of the TCP data; Send an update session key command to the Netty Channel to synchronize the second key to the TCP communication link.

7. The method according to claim 6, characterized in that, The method further includes: Determine the continuity of valid bits in the frame count; If the valid bits of the frame count do not change consecutively, the TCP communication connection will be interrupted. If the valid bits of the frame count are consecutive, the TCP communication connection continues.

8. A security verification system based on the Netty architecture, characterized in that, The Netty architecture transport layer includes a trusted state processor; The trusted state processor is configured to read trusted verification metadata from the byte buffer container ByteBuf via pointer offset in response to the IEC104 protocol decoder parsing TCP data. Based on the trusted verification metadata, the TCP data is subjected to trusted verification. If the trusted verification is successful, the TCP data is transparently transmitted to the business logic processor.

9. A control device, characterized in that, It includes a processor and a memory, the memory being used to store programs, instructions, or code, and the processor being used to execute the programs, instructions, or code in the memory to perform the security verification method based on the Netty architecture as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The system contains a computer program that is loaded by a processor to execute the security verification method based on the Netty architecture as described in any one of claims 1-7.

Images