A containerized security management and protocol adaptation method for intelligent converged terminals in low-voltage distribution networks

Abstract

This invention discloses a containerized security management and protocol adaptation method for intelligent converged terminals in low-voltage distribution networks, relating to the field of power distribution network automation technology. This invention proposes a containerized end-to-end security management method for terminals, using a national cryptographic hardware security module as the root of trust to achieve step-by-step verification upon startup, business container isolation, operation monitoring, image security upgrades, closed-loop operation and maintenance management, and log auditing. Simultaneously, it proposes a multi-protocol adaptive interface adaptation method, which can automatically identify hardware interfaces, dynamically load protocol stacks, complete national cryptographic security authentication, establish intelligent data paths, and achieve adaptive management and control of communication links.

Description

Technical Field

[0001] This invention belongs to the field of power system distribution network automation technology, specifically relating to a containerized security management and protocol adaptation method for intelligent integrated terminals in low-voltage distribution networks. Background Technology

[0002] With the comprehensive and in-depth advancement of the construction of new power systems, low-voltage distribution networks, as key hubs and core links in the multi-dimensional collaborative interaction of power generation, grid, load, and storage, are undergoing rapid digital and intelligent upgrades. As core edge computing and control nodes on the distribution transformer side, intelligent converged terminals for low-voltage distribution networks have become the core carrier for realizing panoramic status perception of low-voltage distribution areas, precise equipment control, multi-service edge computing, and data interaction between upper and lower levels. Currently, within the power industry, intelligent converged terminals are rapidly developing towards hardware self-controllable platformization, software decoupling and containerization, and diversified business integration. These terminals need to simultaneously support multi-professional and multi-vendor business applications such as power marketing, distribution automation, distributed power source management, and integrated energy services on the same hardware platform. They also need to connect to a massive number of diverse sensing and control devices with varying communication protocols within the distribution transformer area. This places simultaneous and higher demands on the terminal's end-to-end security protection capabilities in its containerized operating environment and its adaptive adaptation capabilities across multiple protocol interfaces. Furthermore, these two capabilities need to be deeply coordinated to ensure the safe, stable, and efficient operation of the terminal in multi-service convergence scenarios.

[0003] Currently, most existing solutions for containerized security management of intelligent converged terminals focus only on the allocation and isolation of basic hardware resources such as CPU and memory. They only achieve basic resource isolation between different business applications and fail to build a complete trusted verification chain from the hardware-level root of trust to the application within the container. During the terminal power-on process, only the bootloader and operating system kernel are checked for basic integrity. The container runtime, container base image, business application image, and protocol stack image are not included in the scope of hierarchical trusted measurement. The trusted verification chain has obvious risks of breakage and cannot identify and control illegal tampering of container images and protocol stack programs throughout the entire process. This makes it difficult to meet the mandatory requirements of information security level protection and compliant application of national cryptographic algorithms in the power industry. Meanwhile, existing containerized security management solutions have a coarse-grained management scope, failing to accurately bind hardware interface access permissions to business containers, and lacking a synchronous management mechanism for interface permission changes. When the access status and access permissions of terminal hardware interfaces change, the access control policies of the corresponding containers cannot be updated synchronously, making it easy to encounter management vulnerabilities for unauthorized access. Furthermore, existing solutions do not build an independent containerized isolation environment for protocol stack operation. Protocol stack programs and business applications are co-located in the same container, which not only affects the stable operation of business applications when the protocol stack malfunctions, but also fails to achieve independent security verification and lifecycle management of the protocol stack program, making it difficult to adapt to the flexible requirements of dynamic loading of multiple protocols.

[0004] Regarding the multi-protocol interface adaptation technology for intelligent converged terminals, most existing solutions adopt a static binding of hardware interfaces and communication protocols, with fixed pre-loading of protocol stacks. This requires fixed configuration of interfaces and protocols before the terminal leaves the factory, or manual configuration of protocol parameters by maintenance personnel at the engineering site. This approach cannot achieve full automatic identification of terminal hardware interfaces or dynamic on-demand loading of protocol stacks. The accuracy and efficiency of protocol matching are low, failing to meet the plug-and-play access requirements of multi-vendor, multi-type, and multi-protocol sensing and control devices in low-voltage distribution areas, and also struggling to adapt to scenarios with dynamic expansion of terminal services. Furthermore, the communication protocol stacks in existing solutions mostly run directly at the terminal system kernel layer without containerized isolation. Vulnerabilities and operational anomalies in the protocol stack program itself can directly breach the entire terminal's system security protection system, causing the terminal's containerized security isolation mechanism to completely fail. Moreover, the identity authentication and data encryption protection in the existing protocol adaptation process are not deeply coupled with the terminal's hardware-level security modules, and the generation, storage, and use of session keys do not achieve full lifecycle hardware-level security control. This does not comply with the mandatory requirements for the compliant application of national cryptographic algorithms in the power industry, posing security risks of data leakage and instruction tampering. More importantly, in existing technologies, the containerized security management system and the multi-protocol interface adaptation system of the terminal are completely independent of each other, and no effective deep linkage and collaborative management has been formed. The loading and operation of the protocol stack are not included in the trusted verification scope of containerized security management, and changes in interface permissions cannot trigger the update of container security management policies in a synchronous manner. This results in obvious blind spots in the terminal's security protection system, making it impossible to achieve flexible adaptive adaptation of multi-protocol interfaces while ensuring high-level security protection of the terminal. It is also difficult to meet the comprehensive requirements of intelligent converged terminals for operational security, business compatibility, and scenario adaptability in new power system scenarios.

[0005] In summary, existing technologies cannot solve the problem of collaborative optimization between containerized security management and multi-protocol interface adaptation of intelligent integrated terminals in low-voltage distribution networks. They cannot achieve deep linkage between the two core capabilities, are difficult to adapt to the complex scenario requirements of multi-service integration and multi-device access in low-voltage distribution areas during the construction of new power systems, and cannot fully meet the relevant regulatory requirements of the power industry for the safety compliance, stable operation, and flexible expansion of terminal equipment. Summary of the Invention

[0006] To address the aforementioned technical issues, this invention provides a containerized security management and protocol adaptation method for intelligent converged terminals in low-voltage power distribution networks.

[0007] The specific details of the invention are as follows:

[0008] Firstly, a containerized end-to-end security management method for a low-voltage distribution network intelligent converged terminal is applied to a low-voltage distribution network intelligent converged terminal equipped with an embedded Linux operating system, a nationally compliant embedded hardware security module, and an independently controllable multi-core main control unit. The method includes steps such as terminal startup verification, containerized deployment, operational status monitoring, application upgrade management, operation and maintenance management, and audit log management. These steps are executed sequentially according to the physical order of the terminal's power-on operation:

[0009] S1 Full-Chain Trusted Boot and Verification: After the terminal is powered on, the hardware security module is used as the sole trusted root. The Bootloader image, operating system kernel image, critical system configuration files, container runtime program, business container base image, protocol stack base image, and application within the container are sequentially verified using the national cryptographic SM3 integrity verification and the national cryptographic SM2 digital signature verification. If the verification fails, the boot process of the corresponding level is terminated and the corresponding alarm register is set.

[0010] S2 containerized security isolation deployment: Based on the Linux kernel's cgroups and namespace mechanism, independent business containers with mutually isolated resources are created according to three business categories: power marketing, power distribution, and integrated energy. Each container is bound with a dedicated CPU core, memory partition, storage partition, and hardware interface access whitelist. Independent network namespaces and firewall rules based on the Linux kernel's netfilter / iptables are configured, as well as cross-container unauthorized access prohibition rules. Whitelist updates can only be executed through authorized commands issued by the power master station and verified by the hardware security module.

[0011] S3 container runtime security monitoring: Real-time collection of runtime and interaction data of terminal systems, containers and applications, hierarchical handling of abnormal events according to preset rules, and synchronous writing of all events to the audit log;

[0012] S4 containerized image security upgrade: Receives upgrade package from power master station, performs national cryptographic SM2 signature verification and SM3 integrity verification through hardware security module, creates new container to load upgrade image after verification, switches service traffic after service connectivity test, and automatically rolls back in case of abnormality;

[0013] S5 terminal operation and maintenance security management: Local Bluetooth, USB and Ethernet maintenance interfaces are disabled by default. After receiving the operation and maintenance authorization instruction verified by the main station, the corresponding interface is enabled in the authorization window. After two-way identity authentication based on the national cryptographic algorithm, a temporary operation and maintenance container is created. Operation and maintenance operations are restricted to this container. After the window expires, the container is destroyed and the interface is disabled.

[0014] S6 audit log full-process control: Collect all security event logs and store them in a structured manner. Through the hardware security module, execute the national cryptographic SM3 hash and SM2 digital signature at preset cycles. Write the signature value to the secure storage area. The log is synchronized to the main station through an encrypted channel.

[0015] Preferably, in the S1 full-chain trusted boot and verification step, after each level of verification is passed, the measurement result is written to the trusted storage area of ​​the hardware security module; the verification benchmark value of the Bootloader image is preset in the one-time programmable storage area of ​​the hardware security module; the verification benchmark values ​​of the operating system kernel image, container runtime program, business container base image, and protocol stack base image are all written to the trusted storage area after being verified and signed by the hardware security module.

[0016] Preferably, in the S3 container runtime security monitoring step, the collected events are classified according to the event classification rules preset in accordance with the information security level protection requirements of the power industry and the Q / GDW10376 series standards. Level 1 events include unauthorized creation or destruction of business containers, container image tampering, unauthorized access to hardware security module interfaces, control instruction signature verification failure, and unauthorized hardware interface access, resulting in the termination of the business container process and the blocking of access permissions for the corresponding hardware interface. Level 2 events include the continuous exceedance of the preset threshold of the Q / GDW10376 series standards for the CPU or memory usage of the business container, abnormal container restart, and data integrity verification error, resulting in the execution of business container resource rate limiting. Level 3 events include the business container resource usage approaching the preset threshold of the Q / GDW10376 series standards, normal restart of the application process, and temporary interruption of the communication link, which are written to the local event log.

[0017] Preferably, in the S4 containerized image security upgrade step, the service traffic switching adopts a packet-by-packet switching mode; after the old container completes the traffic switching, it retains a 24-hour window period for destruction that conforms to the power terminal operation and maintenance specifications, and is automatically destroyed after the window period ends; in the S6 audit log full-process control step, national cryptographic signatures are executed at fixed intervals of 15 minutes, 1 hour, and 24 hours that conform to the power terminal security audit specifications; in the S2 containerized security isolation deployment step, the firewall rules of the corresponding service container are updated synchronously after the whitelist is updated.

[0018] Secondly, a multi-protocol adaptive interface adaptation method for a low-voltage distribution network intelligent fusion terminal is applied to a low-voltage distribution network intelligent fusion terminal equipped with an embedded Linux operating system, a national cryptographic compliant embedded hardware security module, and an independently controllable multi-core main control unit. The terminal is configured with a containerized secure operating environment verified by national cryptographic full-link trust. The method includes hardware interface identification, protocol stack loading, communication link authentication, data path establishment, and communication link management steps, including the following steps executed in sequence:

[0019] S1 Hardware Interface Full Automatic Identification: When the terminal system completes startup or detects a change in the status of the hardware communication interface module, it obtains the module's presence status through hardware status pin level scanning, reads the device identification code and function parameter table built into the module, and performs automatic negotiation with the access device through a preset protocol frame sequence conforming to the Q / GDW10376 series standards; identifies the type, hardware parameters, and communication capabilities of the hardware communication interface module, and generates a panoramic ledger of terminal interface resources; synchronizes the panoramic ledger of interface resources to the container security management module and updates the hardware interface access whitelist of the corresponding business container;

[0020] S2 Protocol Stack Dynamic Matching and Containerized Loading: Based on the interface identification results, the system matches the corresponding main protocol stack and auxiliary protocol stack for each hardware interface from the terminal's pre-built standardized protocol library; it then sends a protocol stack container creation request to the container security management module, which retrieves the pre-built protocol stack image baseline value from the hardware security module and performs SM3 integrity verification and SM2 signature verification on the protocol stack image, both completed by the hardware security module; if the verification passes, an independent protocol stack container is created, and the container is assigned exclusive access permissions to the corresponding hardware interface, completing the protocol stack initialization and resource configuration; if the protocol stack loading fails, the system triggers the interface re-identification and protocol stack retry loading process, and writes an error log.

[0021] S3 communication link full-link security authentication: Based on the hardware security module, it performs two-way identity authentication with the communication peer device based on the national cryptographic SM2 algorithm; if the authentication fails, the communication link establishment process is terminated; if the authentication is successful, a temporary key for this communication session is generated through the national cryptographic SM4 algorithm in the hardware security module, and the temporary key is stored in the session key area of ​​the hardware security module, and the key access permission is only granted to the corresponding protocol stack container.

[0022] S4 Multi-Protocol Data Path Intelligent Establishment: Based on protocol stack loading results and security authentication results, a virtual communication routing table is generated and maintained; end-to-end data routing relationships are established between hardware communication interfaces, protocol stack containers, and upper-layer business containers; rules for parsing, encapsulating, and bidirectionally converting protocol frames are configured; the virtual communication routing table can only be updated when the hardware interface identification result changes, the protocol stack container status changes, or the business container permissions change; routing table update operations are written to the audit log; and the routing table is only open to modification permissions by the container security management module.

[0023] S5 communication link full lifecycle adaptive management and control: continuously collects communication status, protocol interaction data, and link quality indicators of hardware interfaces; based on the communication quality thresholds preset in accordance with Q / GDW10376.2 and Q / GDW10376.3 standards, performs adaptive adjustment of communication parameters, switching of backup channels, link reset and protocol stack restart operations in order of priority; synchronizes the link status and operation events to the audit module and writes them into the full communication process log.

[0024] Preferably, in the S1 hardware interface full automatic identification step, the identified hardware communication interface module types include three categories: remote communication module, local communication module, and extended communication module. Specifically: for remote communication modules, the identification content includes communication standard, frequency band parameters, and positioning capability; for local communication modules, the identification content includes communication type, communication frequency band, and networking mode parameters; and for extended communication modules, the identification content includes interface type, number of interfaces, baud rate range, and electrical parameters.

[0025] Preferably, in the S2 protocol stack dynamic matching and containerized loading step, the protocol stack matching rules are as follows: if identified as a local communication module, the Q / GDW10376.2 main protocol stack is matched and loaded first, and the DL / T645, Modbus, and DL / T842 auxiliary protocol stacks are matched and loaded as needed; if identified as a remote communication module, the Q / GDW10376.3 main protocol stack is matched and loaded first, and the DL / T634.5101, DL / T634.5104, Q / GDW11778, and MQTT auxiliary protocol stacks are matched and loaded as needed; if identified as an extended communication module, the communication protocols supported by the access device are matched by polling with broadcast frames in the priority order of DL / T842, DL / T645, and ModbusRTU, and the corresponding protocol stack is loaded after locking the protocol type.

[0026] Preferably, in the S5 communication link full lifecycle adaptive management and control steps, the priority rules for operation execution are as follows: First priority: adaptive adjustment of communication parameters. When any indicator of the communication link's success rate, bit error rate, signal strength, or response delay is continuously lower than a preset threshold, the baud rate, transmission interval, retransmission count, and frame length parameters of the communication protocol are adjusted. Second priority: backup channel switching. If the indicators are still continuously lower than the preset threshold after parameter adjustment, the system switches to a backup communication channel of the same type. Third priority: fault self-healing. When a communication link interruption, protocol interaction timeout, or frame parsing error is detected, link reset, protocol stack restart, and interface renegotiation operations are performed. If the fault cannot self-heal, a fault alarm log is generated and reported to the power master station.

[0027] Preferably, in the S3 communication link full-link security authentication step, the generated session temporary key is set to a 24-hour validity period that conforms to the power industry information security specifications. After the validity period expires, the key update process is automatically triggered, and the updated key is still stored in the session key area of ​​the hardware security module.

[0028] Preferably, in the S2 protocol stack dynamic matching and containerized loading step, the created protocol stack container and the business container are configured with independent network namespaces and access whitelists, allowing only the protocol stack container to interact with the corresponding authorized business container, and directly blocking unauthorized cross-container access.

[0029] The beneficial effects of this invention lie in its construction of a full-chain, step-by-step trusted startup verification mechanism with a nationally compliant embedded hardware security module as the sole trusted root. Combined with containerized security isolation deployment by power business partitioning, full lifecycle container runtime security monitoring, closed-loop operation and maintenance security management, and full-process audit log management, it achieves full-chain security management of the containerized operating environment of intelligent converged terminals for low-voltage distribution networks. This effectively fills the gaps in existing technologies, such as broken trusted measurement chains, insufficient security management granularity, and vulnerabilities in access control. Furthermore, it achieves full automatic identification of hardware interfaces, dynamic matching and loading of containerized protocol stacks, and deep integration with the container security management module. The link national cryptographic security certification, intelligent data path establishment, and adaptive management and control of the entire communication link lifecycle enable adaptive adaptation of multiple types of terminal communication interfaces and multiple industry standard protocols. This significantly improves the terminal's compatibility with multiple types of low-voltage distribution area equipment and its plug-and-play adaptation efficiency. Through the deep linkage between the security management system and the protocol adaptation system, while ensuring that the terminal fully complies with the relevant requirements of national cryptographic compliance and information security level protection in the power industry, it effectively improves the reliability of terminal operation, the security of business isolation, and the adaptability to multiple business scenarios. This fully meets the high security, high compatibility, and high reliability operation requirements of intelligent integrated terminals for low-voltage distribution networks in the construction of new power systems. Attached Figure Description

[0030] Figure 1 Schematic diagram of the hardware architecture of a smart converged terminal for low-voltage distribution networks;

[0031] Figure 2 Schematic diagram of containerized software architecture for intelligent converged terminals in low-voltage distribution networks;

[0032] Figure 3 : Schematic diagram of containerized business application deployment for intelligent converged terminals. Detailed Implementation

[0033] The following embodiments illustrate the present invention in detail. In the description of these embodiments, specific details such as particular system structures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods are omitted so as not to obscure the description of this application with unnecessary detail.

[0034] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0035] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0036] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0037] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0038] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0039] Example 1

[0040] After the terminal is powered on, the first step is to execute the full-chain trusted boot and verification process. The embedded hardware security module first calculates the SM3 hash value of the Bootloader image and compares it with the baseline value pre-installed in the ESAM One-Time Programmable (OTP) storage area. If the verification is successful, the Bootloader is allowed to boot, and the measurement result is extended and recorded in the ESAM trusted storage area. After the Bootloader starts, the embedded hardware security module is invoked to perform integrity measurements on the operating system kernel image, / etc / fstab, / etc / passwd, and other critical system configuration files. The measurement results are extended and recorded in the ESAM trusted storage area. If the verification is successful, the operating system kernel boot is completed. After the operating system boots, the containerd runtime program is subjected to SM2 hash calculations. The system performs digital signature verification and SM3 integrity verification. After successful verification, the container runtime environment is started, and the measurement results are extended and recorded in the ESAM trusted storage area. Before the business container instance starts, the system performs SM2 digital signature verification and SM3 integrity measurement on the basic images of the marketing, power distribution, and integrated energy business containers, as well as the protocol stack basic images such as Q / GDW10376.2. Before the application in the container starts, the system performs integrity verification on the application binary files, core configuration files such as core.conf, etc. After each level of verification passes, the measurement results are written to the ESAM trusted storage area. If the verification fails, the startup process of the corresponding level is immediately terminated, the corresponding alarm register in ESAM is set, and the terminal LED red alarm light is triggered to stay on.

[0041] After the system's trusted boot is completed, the containerized security isolation deployment steps are executed. The container management module, based on the Linux kernel's cgroupsv2 and namespace mechanism, creates three independent business containers with mutually isolated resources, categorized into three business areas: power marketing, power distribution, and integrated energy. For the marketing container, an access whitelist is bound to CPU core 0, a 2GB memory partition, a 16GB storage partition, RS-485 interface 1, and the local communication module. For the power distribution container, an access whitelist is bound to CPU core 1, a 2GB memory partition, a 16GB storage partition, RS-485 interface 2, and the CAN interface. For the integrated energy container, an access whitelist is bound to CPU core 2, a 1GB memory partition, an 8GB storage partition, and the Ethernet interface. Each business container is configured with an independent network namespace and firewall rules based on the Linux kernel's netfilter / iptables, and DROP rules for unauthorized cross-container network access are configured. Updates to the hardware interface access whitelist can only be executed through authorized commands issued by the power master station and verified by the embedded hardware security module SM2. After the whitelist is updated, the corresponding business container's iptables firewall rules are updated synchronously.

[0042] After container deployment, a container runtime security monitoring procedure is performed. The security monitoring module collects terminal system kernel events, business container lifecycle events, container system call events, network interaction packets, and hardware interface access commands in real time through kernel eBPF probes. The collected events are classified according to the event classification rules preset in accordance with the Level 3 requirements of the power industry information security protection system and the Q / GDW10376 series standards. For Level 1 events, the business container process is immediately terminated, and the corresponding hardware interface access permissions are blocked, and the event is reported to the power master station security management platform within 2 minutes. For Level 2 events, the CPU / memory resources of the business container are limited to 50% of the preset threshold, and the event is reported to the master station every 15 minutes. For Level 3 events, they are written to a local circular event log and reported only during master station invocation. All collected events are synchronously written to an encrypted audit log file.

[0043] Upon receiving an upgrade command for the low-voltage data acquisition app from the power master station, a containerized image security upgrade procedure is executed. The upgrade package in tar.gz format is received from the power master station, and the upgrade package undergoes SM2 signature verification and SM3 integrity verification via an embedded hardware security module. After successful verification, a new isolated container instance is created in the terminal resource pool, the upgraded low-voltage data acquisition app image is loaded, and image initialization is completed. Then, 100 simulated meter reading requests are sent to the new container to perform a business health check. After successful testing, a packet-by-packet switching mode is used to switch business traffic from the old container to the new container. After the old container completes all existing meter reading tasks, it enters a pending destruction state, retaining a 24-hour pending destruction window period that conforms to the power terminal operation and maintenance specifications. If the new container experiences an anomaly during the window period, it can be immediately rolled back. After the window period ends, the old container is automatically destroyed and resources are released. If the meter reading success rate of the new container is detected to be below 97% during the switching process, all business traffic is immediately switched back to the old container, the new container instance is automatically destroyed, and an upgrade failure alarm log is generated.

[0044] When maintenance personnel need to perform local debugging on the terminal, the terminal maintenance security control steps are executed. The terminal's local Bluetooth, USB, and Ethernet maintenance interfaces are disabled by default. Maintenance personnel submit a maintenance request to the power master station, which generates a timestamped maintenance authorization instruction and signs it using the master station's private key with SM2. After receiving the maintenance authorization instruction, the terminal verifies the signature using the pre-set master station public key via the embedded hardware security module. Upon successful verification, the corresponding USB maintenance interface is enabled within a preset 2-hour authorization window. Two-way authentication based on the national cryptographic SM2 algorithm is performed on the accessed maintenance tools. After successful authentication, a temporary maintenance container is created. All maintenance operations are restricted to the temporary maintenance container. Network isolation rules are configured between the temporary maintenance container and all business containers, prohibiting the maintenance container from accessing the storage partitions and network interfaces of business containers. After the maintenance window expires, the temporary maintenance container is automatically destroyed, all temporary data and session keys are cleared, the USB maintenance interface is disabled, and a complete maintenance operation log is written to the audit system.

[0045] The entire process of auditing logs is managed step-by-step. It collects full logs of terminal startup events, container running events, hardware interface access events, application interaction events, and maintenance operation events, and stores the logs in JSON structured format. Through an embedded hardware security module, the log files are subjected to SM3 hash calculations and SM2 digital signatures at fixed intervals of 15 minutes, 1 hour, and 24 hours, conforming to the power terminal security audit specifications. The signature values ​​are written to the secure storage area of ​​ESAM, and the encrypted log files are synchronized to the power station security audit platform via a national cryptographic SSL encrypted channel.

[0046] Example 2

[0047] Upon completion of the terminal system startup or upon detecting status changes such as hot-plugging, power-on, offline, or fault reset of the hardware communication interface module, a full automatic hardware interface identification process is executed. The interface identification module obtains the module's presence status through hardware status pin level scanning, reads the module's built-in I2C device identifier and function parameter table, and performs automatic negotiation with the access device using a preset protocol frame sequence conforming to the Q / GDW10376 series standards; identifies the type, hardware parameters, and communication capabilities of the hardware communication interface module, and generates a comprehensive ledger of terminal interface resources; the comprehensive ledger of interface resources is synchronized to the container security management module to update the hardware interface access whitelist of the corresponding business container. Specifically, for remote communication modules, the identification content includes 4G / 5G communication standard, Band3 / Band8 frequency band parameters, and BeiDou-3 positioning capability; for local communication modules, the identification content includes HPLC / low-power wireless / dual-mode communication type, 2-12MHz communication frequency band, and central coordinator / node networking mode parameters; for extended communication modules, the identification content includes RS-485 / CAN / Ethernet interface type, number of 2 interfaces, baud rate range of 1200bps~115200bps, and ±15kV electrostatic protection electrical parameters.

[0048] Based on the interface identification results, the protocol stack dynamic matching and containerization loading steps are executed. The protocol adaptation module matches the corresponding main protocol stack and auxiliary protocol stack for each hardware interface from the terminal's pre-installed standardized protocol library; it initiates a protocol stack container creation request to the container security management module, which retrieves the pre-installed protocol stack image baseline value in the embedded hardware security module and performs national cryptographic SM3 integrity verification and national cryptographic SM2 signature verification on the protocol stack image, which is completed by the embedded hardware security module; after the verification is successful, an independent protocol stack container is created, and exclusive access permissions for the corresponding hardware interface are assigned to the protocol stack container, completing the initialization and resource configuration of the protocol stack; the created protocol stack container and the business container are configured with independent network namespaces and access whitelists, allowing only the protocol stack container to communicate with the corresponding authorized business container via TCP port 8080, and unauthorized cross-container access is directly blocked by iptables rules; if the protocol stack loading fails, the interface re-identification and protocol stack retry loading process is triggered, and if loading fails three times consecutively, an exception log is generated and reported to the main station. The specific protocol stack matching rules are as follows: If identified as a local communication module, the Q / GDW10376.2 main protocol stack is matched and loaded first, and the DL / T645-2007, Modbus-RTU, and DL / T842 auxiliary protocol stacks are matched and loaded as needed; if identified as a remote communication module, the Q / GDW10376.3 main protocol stack is matched and loaded first, and the DL / T634.5101, DL / T634.5104, Q / GDW11778, and MQTTv3.1.1 auxiliary protocol stacks are matched and loaded as needed; if identified as an extended communication module, the communication protocols supported by the access device are matched by polling with broadcast frames in the priority order of DL / T842, DL / T645-2007, and Modbus-RTU. The polling timeout for a single protocol is preset to 500ms. If there is no response after 3 consecutive polls, the system switches to the next priority protocol, locks the protocol type, and loads the corresponding protocol stack.

[0049] After the protocol stack is loaded, the full-link security authentication process is executed. The security interaction module, based on the embedded hardware security module, performs two-way authentication with the peer device using the national cryptographic SM2 algorithm, exchanges digital certificates between the two parties, and verifies the legality of the certificate chain. If authentication fails, the communication link establishment process is immediately terminated, and an alarm log for unauthorized device access is generated. If authentication is successful, a 128-bit temporary key for this communication session is generated using the national cryptographic SM4 algorithm within the embedded hardware security module. The temporary key is stored in the ESAM session key area and is only accessible to the corresponding protocol stack container. The generated session temporary key is set with a 24-hour validity period as per the power industry information security standards. Upon expiration, the key update process is automatically triggered, and the updated key is still stored in the ESAM session key area, while the old key is immediately destroyed.

[0050] After security authentication is successful, the intelligent establishment of multi-protocol data paths is executed. Based on the protocol stack loading result and security authentication result, the routing management module generates and maintains a virtual communication routing table; establishes end-to-end data routing relationships between hardware communication interfaces, protocol stack containers, and upper-layer business containers; configures rules for protocol frame parsing, encapsulation, and bidirectional conversion to achieve data format conversion between different communication protocols; the virtual communication routing table can only be updated when the hardware interface identification result changes, the protocol stack container status changes, or the business container permissions change. Routing table update operations must be written to the audit log, and the routing table only has root modification permissions granted to the container security management module.

[0051] After the data path is established, the adaptive management and control steps for the entire lifecycle of the communication link are executed. The link monitoring module continuously collects the communication status, protocol interaction data, and link quality indicators of the hardware interface, and performs real-time statistics on key indicators such as communication success rate, bit error rate, signal strength, and response latency. Based on the communication quality thresholds preset according to the Q / GDW10376.2 and Q / GDW10376.3 standards, the module executes communication parameter adaptive adjustment, backup channel switching, link reset, and protocol stack restart operations in order of priority. The first priority is communication parameter adaptive adjustment. When the communication success rate is below 97% for three consecutive collection periods, the bit error rate is above 1% for three consecutive collection periods, the signal strength is below -90dBm for three consecutive collection periods, and the response latency is above 50dBm for three consecutive collection periods, the adjustment will be prioritized. When any metric is 0ms, the baud rate of the communication protocol is automatically adjusted from 9600bps to 2400bps, the transmission interval is increased from 1s to 2s, the number of retransmissions is increased from 3 to 5, and the frame length is reduced from 256 bytes to 64 bytes. The second priority is backup channel switching. If the metric remains below the preset threshold after parameter adjustment, the system automatically switches to a backup communication channel of the same type. The third priority is fault self-healing. When a communication link interruption, protocol interaction timeout, or frame parsing error is detected, the system performs link reset, protocol stack restart, and interface renegotiation. If the fault cannot heal itself, a fault alarm log is generated and reported to the power master station. The link status and operation events are synchronized to the audit module and written into the full communication process log.

[0052] Example 3

[0053] Reference Appendix Figure 3In this embodiment, the terminal deploys five business applications: a system manager, a wireless remote dialing management APP, a local communication management APP, a low-voltage data acquisition APP, and a low-voltage smart circuit breaker interaction APP. Each business application runs in an independent container. The system manager runs in the system container, has the highest system privileges, and is responsible for the overall resource scheduling and system management of the terminal. The wireless remote dialing management APP runs in the dialing container, has only access permissions to the remote communication module, and is responsible for the remote communication connection between the terminal and the power station. The local communication management APP runs in the local communication container, has only access permissions to the local communication module, and is responsible for the communication connection between the terminal and the electricity meters in the distribution area. The low-voltage data acquisition APP runs in the data collection container, has only access permissions to the local communication protocol stack container, and is responsible for the collection and processing of electricity meter data in the distribution area. The low-voltage smart circuit breaker interaction APP runs in the circuit breaker container, has only access permissions to the RS-485 protocol stack container, and is responsible for the status monitoring and remote control of the smart circuit breakers in the distribution area.

[0054] When the construction worker connects a new Chint NA1 intelligent circuit breaker to the idle RS-485 interface 2 of the terminal, the interface identification module immediately detects the change in the line status of the RS-485 interface and initiates the full automatic hardware interface identification process. It confirms the module's presence by scanning the hardware status pin levels, reads the built-in device identifier 0x12345678 and the function parameter table, and obtains the interface baud rate range of 1200bps~19200bps. Subsequently, it initiates the automatic protocol negotiation process according to DL / T842, DL / T645-2007, and Modbus. - The RTU sends broadcast query frames in priority order; after sending the identity query frame of the DL / T842 protocol, the smart circuit breaker replies with a response frame conforming to the DL / T842 protocol format. The negotiation unit immediately locks the protocol type of the interface as DL / T842, records the communication parameters of the device such as communication address 0x01, baud rate 9600bps, 8 data bits, none parity bit, and 1 stop bit; generates a panoramic ledger of interface resources and synchronizes it to the container security management module. The container security management module updates the hardware interface access whitelist of the circuit breaker container, allowing it to access RS-485 interface 2.

[0055] Based on the interface identification result, the protocol adaptation module initiates a DL / T842 protocol stack container creation request to the container security management module. The container security management module retrieves the pre-set DL / T842 protocol stack image baseline value in the embedded hardware security module and performs national cryptographic SM3 integrity verification and national cryptographic SM2 signature verification on the protocol stack image. After the verification is successful, an independent DL / T842 protocol stack container is created, and exclusive access permissions for RS-485 interface 2 are assigned to it, and the communication parameters of the protocol stack are configured. At the same time, an access whitelist is configured between the circuit breaker container and the DL / T842 protocol stack container, allowing only the circuit breaker container to access the protocol stack container through TCP port 8080. The routing management module updates the virtual communication routing table and establishes an end-to-end data routing relationship between the circuit breaker container, the DL / T842 protocol stack container, and RS-485 interface 2.

[0056] The secure interaction module, based on an embedded hardware security module, performs bidirectional authentication with the smart circuit breaker using the national cryptographic SM2 algorithm to verify the legality of the circuit breaker's digital certificate. After successful authentication, a temporary key for this communication session is generated using the national cryptographic SM4 algorithm within the embedded hardware security module. This temporary key is stored in the ESAM session key area, with key access permissions only granted to the DL / T842 protocol stack container. At this point, the smart circuit breaker completes plug-and-play access, and the low-voltage smart circuit breaker interaction APP can achieve secure data interaction with the smart circuit breaker through this data path, collecting real-time operating data such as current, voltage, temperature, and opening / closing status of the circuit breaker, and issuing remote opening / closing and setting modification control commands.

[0057] Example 4

[0058] This embodiment details the implementation of event classification and escalation rules in container runtime security monitoring. The security monitoring module collects terminal operation data in real time. When it detects an unauthorized process attempting to create a new business container, it is determined as a Level 1 high-risk event. The container process is immediately terminated, all hardware interface access permissions of the corresponding process are blocked, and the alarm information is reported to the power station security management platform within 2 minutes. At the same time, the event is written to the audit log. When it detects that the CPU utilization rate of the marketing container exceeds the preset threshold of 80% for 5 consecutive minutes, it is determined as a Level 2 alarm event. The container CPU resources are limited to 40%, and the alarm information is reported to the main station every 15 minutes. When it detects that the local communication link is temporarily interrupted for 10 seconds and then automatically recovers, it is determined as a Level 3 notification event. The event is only written to the local circular log and is not actively reported.

[0059] The specific implementation of the event escalation rules is as follows: When the same Level 3 alert event is triggered more than 10 times within a 1-hour statistical period, it is automatically escalated to a Level 2 alarm event; for example, when the local communication link is temporarily interrupted 12 times within 1 hour, the security monitoring module automatically escalates the event to a Level 2 alarm event, executes a local alarm, and reports it to the main station periodically; When the same Level 2 alarm event is triggered more than 5 times within a 24-hour statistical period, it is automatically escalated to a Level 1 high-risk event; for example, when the marketing container CPU utilization exceeds the limit 6 times within 24 hours, the security monitoring module automatically escalates the event to a Level 1 high-risk event, immediately terminates the marketing container process, blocks its hardware interface access permissions, and reports it to the main station in real time.

[0060] Example 5

[0061] This embodiment details the implementation of the automatic rollback mechanism for abnormalities in the secure upgrade of containerized images. When the terminal receives the low-voltage smart circuit breaker interactive APP upgrade package issued by the power master station, it first completes the signature verification and integrity verification of the upgrade package through the embedded hardware security module. After the verification is successful, a brand-new circuit breaker container instance is created, and the upgraded V2.0 version image is loaded. A business health check is performed on the new container, and 10 circuit breaker status query commands and 2 opening and closing control commands are sent to verify the correctness of the response logic. After the health check is successful, the business traffic is switched from the old V1.0 version container to the new V2.0 version container using a packet-by-packet switching mode.

[0062] During the switchover, the link monitoring module detected that the circuit breaker control command response latency of the new container exceeded 1000ms for 10 consecutive times, and there were 2 instances of command execution failure. The security monitoring module immediately determined that the new container was running abnormally and triggered the automatic rollback mechanism. All business traffic was instantly switched back to the old V1.0 version container, and the new V2.0 version container instance was automatically destroyed, releasing the CPU, memory, and storage resources it occupied. At the same time, an upgrade failure alarm log was generated, recording information such as upgrade time, image version, anomaly type, and rollback time, and reported to the power master station. The old container continued to operate normally, ensuring uninterrupted business. Operation and maintenance personnel could view the alarm information and investigate the cause of the upgrade failure at the master station.

[0063] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A containerized end-to-end security management method for a low-voltage distribution network intelligent fusion terminal, applied to a low-voltage distribution network intelligent fusion terminal equipped with an embedded Linux operating system, a nationally compliant embedded hardware security module, and an independently controllable multi-core main control unit, the method comprising the steps of terminal startup verification, containerized deployment, operational status monitoring, application upgrade management, operation and maintenance management, and audit log management, characterized in that, This includes the following steps, which are executed sequentially according to the physical order in which the terminal powers on: S1 Full-Chain Trusted Boot and Verification: After the terminal is powered on, the embedded hardware security module is used as the sole trusted root. The Bootloader image, operating system kernel image, critical system configuration files, container runtime program, business container base image, protocol stack base image, and application within the container are sequentially verified using the national cryptographic SM3 integrity verification and the national cryptographic SM2 digital signature verification. If the verification fails, the boot process of the corresponding level is terminated and the corresponding alarm register is set. S2 containerized security isolation deployment: Based on the Linux kernel's cgroups and namespace mechanism, independent business containers with mutually isolated resources are created according to three business categories: power marketing, power distribution, and integrated energy. Each container is bound with a dedicated CPU core, memory partition, storage partition, and hardware interface access whitelist. Independent network namespaces and firewall rules based on the Linux kernel's netfilter / iptables are configured, as well as cross-container unauthorized access prohibition rules. Whitelist updates can only be executed through authorized instructions issued by the power master station and verified by the embedded hardware security module. S3 container runtime security monitoring: Real-time collection of runtime and interaction data of terminal systems, containers and applications, hierarchical handling of abnormal events according to preset rules, and synchronous writing of all events to the audit log; S4 containerized image security upgrade: Receives upgrade package issued by power master station, performs national cryptographic SM2 signature verification and SM3 integrity verification through embedded hardware security module, creates a new container to load upgrade image after verification, switches service traffic after service connectivity test, and automatically rolls back in case of abnormality; S5 terminal operation and maintenance security management: Local Bluetooth, USB and Ethernet maintenance interfaces are disabled by default. After receiving the operation and maintenance authorization instruction verified by the main station, the corresponding interface is enabled in the authorization window. After two-way identity authentication based on the national cryptographic algorithm, a temporary operation and maintenance container is created. Operation and maintenance operations are restricted to this container. After the window expires, the container is destroyed and the interface is disabled. S6 audit log end-to-end control: Collect all security event logs and store them in a structured manner. Through the embedded hardware security module, execute the national cryptographic SM3 hash and SM2 digital signature at preset cycles. Write the signature value to the secure storage area. The log is synchronized to the main station through an encrypted channel.

2. The containerized end-to-end security management method for a low-voltage distribution network intelligent converged terminal according to claim 1, characterized in that, In the S1 full-chain trusted startup and verification steps, after each level of verification is passed, the measurement result is written to the trusted storage area of ​​the embedded hardware security module; the verification benchmark value of the Bootloader image is preset in the one-time programmable storage area of ​​the embedded hardware security module; the verification benchmark values ​​of the operating system kernel image, container runtime program, business container base image, and protocol stack base image are all written to the trusted storage area after being verified and signed by the embedded hardware security module.

3. The containerized end-to-end security management method for a low-voltage distribution network intelligent converged terminal according to claim 1, characterized in that, In the S3 container runtime security monitoring steps, the collected events are classified according to the event classification rules preset by the power industry information security level protection requirements and the Q / GDW10376 series standards. Level 1 events include unauthorized creation or destruction of business containers, container image tampering, unauthorized access to embedded hardware security module interfaces, control command signature verification failure, and unauthorized hardware interface access, resulting in termination of the business container process and blocking of the corresponding hardware interface access permissions. Level 2 events include business container CPU or memory usage continuously exceeding the preset threshold of the Q / GDW10376 series standards, abnormal container restart, and data integrity verification errors, resulting in rate limiting of business container resources. Level 3 events include business container resource usage approaching the preset threshold of the Q / GDW10376 series standards, normal restart of the application process, and temporary interruption of the communication link, which are written to the local event log.

4. The containerized end-to-end security management method for a low-voltage distribution network intelligent converged terminal according to claim 1, characterized in that, In the S4 containerized image security upgrade step, the service traffic switching adopts a packet-by-packet switching mode; after the traffic switching is completed, the old container retains a 24-hour window period for destruction that conforms to the power terminal operation and maintenance specifications, and is automatically destroyed after the window period ends; in the S6 audit log full-process control step, national cryptographic signatures are executed at fixed intervals of 15 minutes, 1 hour, and 24 hours that conform to the power terminal security audit specifications; in the S2 containerized security isolation deployment step, the firewall rules of the corresponding service container are updated synchronously after the whitelist is updated.

5. A multi-protocol adaptive interface adaptation method for a low-voltage distribution network intelligent fusion terminal, applied to a low-voltage distribution network intelligent fusion terminal equipped with an embedded Linux operating system, a national cryptographic compliant embedded hardware security module, and an independently controllable multi-core main control unit, wherein the terminal is configured with a containerized secure operating environment verified by national cryptographic full-link trust, the method comprising hardware interface identification, protocol stack loading, communication link authentication, data path establishment, and communication link management steps, characterized in that, The following steps are performed in sequence: S1 Hardware Interface Full Automatic Identification: When the terminal system has finished booting up or when a change in the status of the hardware communication interface module is detected, the module's presence status is obtained by scanning the hardware status pin levels. The device identification code and function parameter table built into the module are read, and automatic negotiation is performed with the access device through a preset protocol frame sequence conforming to the Q / GDW10376 series standards. Identify the type, hardware parameters, and communication capabilities of the hardware communication interface module, and generate a comprehensive ledger of terminal interface resources; synchronize the comprehensive ledger of interface resources to the container security management module, and update the hardware interface access whitelist of the corresponding business container. S2 Protocol Stack Dynamic Matching and Containerized Loading: Based on the interface identification results, the system matches the corresponding main protocol stack and auxiliary protocol stack for each hardware interface from the terminal's pre-built standardized protocol library; it then sends a protocol stack container creation request to the container security management module, which retrieves the pre-built protocol stack image baseline value from the embedded hardware security module and performs SM3 integrity verification and SM2 signature verification on the protocol stack image, both completed by the embedded hardware security module; if the verification passes, an independent protocol stack container is created, and the container is assigned exclusive access permissions to the corresponding hardware interface, completing the protocol stack initialization and resource configuration; if the protocol stack loading fails, the system triggers the interface re-identification and protocol stack retry loading process, and writes an error log. S3 communication link end-to-end security authentication: Based on an embedded hardware security module, it performs two-way identity authentication with the peer device based on the national cryptographic SM2 algorithm; if the authentication fails, the communication link establishment process is terminated. After authentication, a temporary key for this communication session is generated using the national cryptographic SM4 algorithm within the embedded hardware security module. The temporary key is stored in the session key area of ​​the embedded hardware security module, and key access is only granted to the corresponding protocol stack container. S4 Multi-Protocol Data Path Intelligent Establishment: Based on protocol stack loading results and security authentication results, a virtual communication routing table is generated and maintained; end-to-end data routing relationships are established between hardware communication interfaces, protocol stack containers, and upper-layer business containers; rules for parsing, encapsulating, and bidirectionally converting protocol frames are configured; the virtual communication routing table can only be updated when the hardware interface identification result changes, the protocol stack container status changes, or the business container permissions change; routing table update operations are written to the audit log; and the routing table is only open to modification permissions by the container security management module. S5 communication link full lifecycle adaptive management and control: continuously collects communication status, protocol interaction data, and link quality indicators of hardware interfaces; based on the communication quality thresholds preset in accordance with Q / GDW10376.2 and Q / GDW10376.3 standards, performs adaptive adjustment of communication parameters, switching of backup channels, link reset and protocol stack restart operations in order of priority; synchronizes the link status and operation events to the audit module and writes them into the full communication process log.

6. The multi-protocol adaptive interface adaptation method for a low-voltage distribution network intelligent converged terminal according to claim 5, characterized in that, In the S1 hardware interface full automatic identification step, the identified hardware communication interface module types include three main categories: remote communication module, local communication module, and extended communication module. Specifically: for remote communication modules, the identification content includes communication standard, frequency band parameters, and positioning capability; for local communication modules, the identification content includes communication type, communication frequency band, and networking mode parameters; and for extended communication modules, the identification content includes interface type, number of interfaces, baud rate range, and electrical parameters.

7. The multi-protocol adaptive interface adaptation method for a low-voltage distribution network intelligent converged terminal according to claim 5, characterized in that, In the S2 protocol stack dynamic matching and containerized loading step, the specific protocol stack matching rules are as follows: If identified as a local communication module, the Q / GDW10376.2 main protocol stack is matched and loaded first, and the DL / T645, Modbus, and DL / T842 auxiliary protocol stacks are matched and loaded as needed; if identified as a remote communication module, the Q / GDW10376.3 main protocol stack is matched and loaded first, and the DL / T634.5101, DL / T634.5104, Q / GDW11778, and MQTT auxiliary protocol stacks are matched and loaded as needed; if identified as an extended communication module, the communication protocols supported by the access device are matched by polling with broadcast frames in the priority order of DL / T842, DL / T645, and ModbusRTU, and the corresponding protocol stack is loaded after locking the protocol type.

8. The multi-protocol adaptive interface adaptation method for a low-voltage distribution network intelligent converged terminal according to claim 5, characterized in that, In the S5 communication link full lifecycle adaptive management and control steps, the priority rules for operation execution are as follows: First priority: adaptive adjustment of communication parameters. When any indicator of the communication link's success rate, bit error rate, signal strength, or response delay is continuously lower than a preset threshold, the baud rate, transmission interval, retransmission count, and frame length parameters of the communication protocol are adjusted. Second priority: backup channel switching. If the indicators are still continuously lower than the preset threshold after parameter adjustment, the system switches to a backup communication channel of the same type. Third priority: fault self-healing. When a communication link interruption, protocol interaction timeout, or frame parsing error is detected, the system performs link reset, protocol stack restart, and interface renegotiation. If the fault cannot self-heal, a fault alarm log is generated and reported to the power master station.

9. The multi-protocol adaptive interface adaptation method for a low-voltage distribution network intelligent converged terminal according to claim 5, characterized in that, In the S3 communication link full-link security authentication step, the generated session temporary key is set to a 24-hour validity period in accordance with the power industry information security specifications. After the validity period expires, the key update process is automatically triggered, and the updated key is still stored in the session key area of ​​the embedded hardware security module.

10. The multi-protocol adaptive interface adaptation method for a low-voltage distribution network intelligent converged terminal according to claim 5, characterized in that, In the S2 protocol stack dynamic matching and containerized loading step, the created protocol stack container and the business container are configured with independent network namespaces and access whitelists, allowing only the protocol stack container to interact with the corresponding authorized business container, and directly blocking unauthorized cross-container access.

Images