Electricity information collection terminal secure access and trusted authentication system

Abstract

The application discloses a system for secure access and trusted authentication of an electric information collection terminal, relates to the technical field of electric power information security, and provides a secure access and trusted authentication method based on terminal security capability and state atlas; the system collects security capability information on the equipment side and the operation observation side in the secure access area, compares the capability deviation, constructs a terminal security capability and state atlas in combination with the operation state, divides the terminal into a plurality of state clusters from the atlas, and configures an access template and a key cluster for each state cluster. When the terminal accesses or initiates a meter reading, fee control or control request, the system selects an access template and a key cluster according to the state cluster to which the terminal belongs, completes authentication and key negotiation, generates a secure context token carrying a state cluster identifier and a key cluster identifier, and implements hierarchical permission control on the business request; operation and maintenance cooperate with the operation and maintenance bill to adjust the terminal state cluster and the key cluster, so that terminal state quantization and access operation and maintenance cooperation are realized.

Description

Technical Field

[0001] This invention relates to the field of power information security technology, specifically to a secure access and trusted authentication system for electricity information collection terminals. Background Technology

[0002] In recent years, with the large-scale application of smart meters, concentrators, electricity information collection terminals, and distribution automation terminals in distribution networks and user-side infrastructure, power companies have generally built electricity information collection systems consisting of a master station system, communication networks, and various field terminals to realize functions such as metering data collection, fee control management, and remote control. In engineering practice, field terminals come from numerous manufacturers, including smart meters, collectors, and concentrators implemented according to different industry protocols, as well as distribution automation terminals and dedicated transformer collection terminals with control functions. Communication methods cover carrier waves, dedicated power networks, public mobile communication networks, and access to power IoT platforms. These terminals operate in open environments such as residential communities and industrial and commercial parks for extended periods, and frequent operations such as field replacement, firmware upgrades, and parameter adjustments occur during operation and maintenance.

[0003] To ensure network and data security for such systems, existing technologies generally protect the main station and important boundaries through network partitioning, secure access zones, encryption authentication gateways, electricity information key management systems, and operation and maintenance bastion hosts. Some terminals use embedded security modules and cryptographic algorithms to encrypt their access and communication. However, due to the large number of terminals, their diverse types and capabilities, the rich network access, and the long maintenance time, existing security mechanisms, which are mainly based on static configuration and decentralized management, still tend to focus on single-point devices or boundary protection in engineering projects. They lack a consistent portrayal of the security status of field terminals at different lifecycle stages, and lack corresponding constraints on the relationship between terminal access control, service access permissions, and the generation, updating, and revocation of keys and certificates. Changes in status caused by firmware upgrades, batch parameter modifications, and table replacements during maintenance cannot be reflected in the security access policy and key lifecycle management in a timely and accurate manner. Some terminals can only be maintained through simple protocol conversion and link encryption. The main station cannot differentiate their security capabilities and risks. When abnormal events or attacks occur, it is impossible to accurately define the scope of the fault and the affected objects. Fault handling and risk isolation require a lot of manual analysis and step-by-step investigation, which undermines the continuity and accuracy of metering, fee control, and remote control services.

[0004] In summary, in the scenario of electricity information collection involving multiple protocols, multiple manufacturers, and a large number of long-term operating terminals, there is still a technical challenge of how to uniformly model and collaboratively manage the access security, business access permissions, and the correspondence between key and certificate lifecycles of field terminals under a unified technical architecture. Summary of the Invention

[0005] (a) Technical problems to be solved To address the shortcomings of existing technologies, this invention provides a secure access and trusted authentication system for electricity information collection terminals. By dividing terminals into multiple state clusters from a graph and configuring access templates and key clusters for each cluster, the system, when a terminal accesses or initiates meter reading, fee control, or control requests, selects an access template and key cluster based on the terminal's state cluster to complete authentication and key negotiation. This generates a security context token carrying both state cluster and key cluster identifiers, enabling tiered access control for service requests. Maintenance personnel, in conjunction with maintenance tickets, adjust the terminal's state cluster and key cluster, achieving terminal state quantification and collaborative access maintenance; thus resolving the technical problems described in the background section.

[0006] (II) Technical Solution To achieve the above objectives, the present invention is implemented through the following technical solution: a secure access and trusted authentication system for electricity information collection terminals, comprising: acquiring security capability information of the equipment side and operation observation side of the electricity information collection terminal at the secure access zone side; comparing the two to obtain capability deviation information; and constructing a terminal security capability and status map with the terminal as the node in combination with the current operating status of the terminal. Capability deviation information and operational characteristics are extracted from the terminal security capability and state graph. The terminals are clustered into multiple state clusters. For each state cluster, an access template is selected from the template library, and a key cluster corresponding to the state cluster is established. When a terminal initiates an access or service request, it determines the state cluster it belongs to based on the state cluster division, selects the access template and key cluster corresponding to the state cluster to complete authentication and key negotiation, and generates a security context token to identify the terminal's state cluster and key cluster. When performing critical operation and maintenance operations on the terminal, the operation and maintenance management system generates operation and maintenance tickets. The operation and maintenance tickets record the operation and maintenance subject and status adjustment rules. The secure access platform verifies the operation and maintenance instructions based on the operation and maintenance tickets and security context tokens, and updates the graph and corresponding key clusters according to the status adjustment rules after execution.

[0007] Furthermore, obtaining safety capability information from both the equipment side and the operational monitoring side includes: Before the initial access, the terminal manufacturer shall report the types of cryptographic algorithms supported by the terminal, the security hardware configuration, the local security storage and security log capabilities, and the operation and maintenance interface types through encrypted messages. During the terminal access and operation process, the platform shall issue security capability self-check tasks and collect statistics on algorithm task completion time, accuracy rate, forged signature firmware interception, port open status, and abnormal retransmission and disconnection.

[0008] Furthermore, when constructing the terminal security capability and status map, capability deviation information, the terminal's current new installation status, debugging status, and running status, as well as the maintenance records of the most recent firmware upgrade, parameter modification, and key reset are used as status features associated with terminal nodes in the map. Connections between nodes are established based on the physical wiring relationship, communication topology relationship, and manufacturing unit origin relationship between terminal nodes to support subsequent status cluster division.

[0009] Furthermore, the terminals are clustered into multiple state clusters, including: aggregating the comprehensive security status features of the terminals according to a preset difference threshold to obtain stable operation state clusters, change observation state clusters, anomaly observation state clusters, and controllable state clusters, and writing the type identifier of each state cluster into the terminal security capability and status map, which is used to identify the state cluster to which the terminal belongs during the access phase and the operation and maintenance phase.

[0010] Furthermore, selecting an access template from the template library and establishing a corresponding key cluster for each state cluster includes: For stable state clusters, an access template including two-way authentication and session key negotiation is selected. For observation and abnormal state clusters, an access template including integrity verification and capability retesting is selected. For access templates of controlled state clusters, a control command confirmation step is added. In the key management system, a key cluster consisting of a root key, a group key, and a personal key is configured for each state cluster.

[0011] Furthermore, generating a security context token when the terminal initiates an access or service request includes: After the terminal completes identity authentication and session key negotiation according to the access template, the secure access platform generates a security context token carrying the terminal identifier, the terminal's state cluster identifier, the key cluster identifier, and the current security state summary field. The token is stored on both the terminal and the secure access platform. Subsequent service packets from the terminal carry the security context token.

[0012] Furthermore, the secure access system performs permission determination based on security context tokens and state cluster configurations, including: For meter reading requests, fee control requests, and control commands carrying security context tokens, the status cluster identifier and current security status summary are read respectively. Terminals in the abnormal observation status cluster and the control status cluster are restricted to only perform business operations within their authorized scope. For business requests that exceed the authorized scope, an authorization denial record is generated and written into the terminal security capability and status graph.

[0013] Furthermore, the maintenance tickets generated by the maintenance management system include: Record the identity of the operation and maintenance personnel, the identity of the operation and maintenance terminal device, the target terminal identity set or target status cluster identity, the set of allowed operation and maintenance operation types, the allowed status adjustment range, and the operation and maintenance time window. In the operation and maintenance ticket, reference the security status summary in the terminal security capability and status graph at the corresponding time for pre-constraint and verification when operation and maintenance instructions are issued.

[0014] Furthermore, the secure access platform verifies operational instructions based on operational tickets and security context tokens, including: When receiving maintenance instructions from the maintenance terminal, the system reads the maintenance personnel's identity, maintenance terminal identifier, target terminal identifier, maintenance operation type, and maintenance ticket number carried in the instruction, compares them with the fields recorded in the maintenance ticket, and checks whether the time is within the maintenance time window. The maintenance instruction is forwarded only if the comparison is consistent and the maintenance ticket is valid.

[0015] Furthermore, after performing maintenance operations, updating the terminal security capabilities and status graph and corresponding key clusters according to the status adjustment rules includes: recording the corresponding maintenance events in the terminal security capabilities and status graph for successfully executed firmware upgrades, parameter modifications, and key reset operations, migrating the terminal node from its original status cluster to the target status cluster, and simultaneously switching the key cluster identifier referenced by the terminal in the key management system and generating status change records and policy change records.

[0016] (III) Beneficial Effects This invention provides a secure access and trusted authentication system for electricity information collection terminals, which has the following advantages: By extracting capability deviations and operational characteristics from the terminal's security capabilities and state graph, terminals are decomposed into stable state clusters, observation state clusters, and controllable state clusters. Access templates and key clusters are configured for these state clusters, enabling unified management of the access authentication process and key policy from access to key acquisition within the state cluster. This avoids the confusion caused by configuring each terminal individually, and allows terminal state changes to be synchronously reflected in the access and key data across different state clusters. When a terminal initiates access, meter reading, fee control, or control services, authentication and encryption are performed based on the state cluster and the access template and key cluster. A security context token with both state cluster and key cluster identifiers is generated and carried in the service message. This ensures that each request is performed within a single security context, implementing different access controls and auditing for different state clusters, and preventing high-risk state cluster terminals from making erroneous accesses or unauthorized operations.

[0017] By introducing maintenance tickets that record the maintenance subject, target terminal, and status adjustment rules in maintenance scenarios such as firmware upgrades, parameter updates, and key deletions, the system verifies the tickets and time windows before executing maintenance instructions on the secure access platform. It updates the terminal security capability and status graph and key cluster configuration according to the ticket rules, providing a clear correspondence between maintenance operations and terminal status modifications and key policy changes, thus preventing arbitrary maintenance from compromising security configurations. Through the synergy between the terminal security capability and status graph, the mapping of status clusters to access templates and key clusters, and the security context token and maintenance tickets, the system achieves unified status descriptions and policy configurations for expressing capability deviations, abnormal events, and maintenance records at each stage from access and operation to maintenance. In multi-terminal operation scenarios, it supports continuous adjustment of status cluster division and security policy allocation, achieving collaborative security control of access control, key management, and maintenance management at the system level. Attached Figure Description

[0018] Figure 1 This is a schematic diagram of the secure access and trusted authentication system for the electricity information collection terminal of the present invention. Detailed Implementation

[0019] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] Please see Figure 1 This invention provides a secure access and trusted authentication system for electricity information collection terminals, including: Step 1: First, establish a device-side security capability file for each electricity information collection terminal, transforming the information originally scattered in technical agreements, factory parameter tables, and field registration forms into a security capability vector that can be uniformly processed by the program.

[0021] Specifically, before the terminal is formally connected to the secure access zone, the terminal manufacturer, during the delivery phase, writes an initialization message containing information such as the types of cryptographic algorithms supported by the terminal, the maximum key length, the model of the built-in security chip, whether it has trusted boot capability, the capacity of local secure storage space, the local security log recording capability, and the type of operation and maintenance interface, according to a pre-agreed data format. After receiving the message, the capability acquisition component in the secure access zone performs field integrity verification and semantic rationality verification against the protocol fields, eliminates missing items and obvious contradictions, and maps the fields that pass the verification to a set of numerical features to form a device-side security capability vector.

[0022] To ensure that terminals from different batches of the same manufacturer can obtain stable vectors during this process, a field mapping table and enumeration value mapping rules are pre-set in the capability acquisition component. A unified numbering convention is adopted for the same type of algorithm, the same level of security chip, or the same type of operation and maintenance interface, so that the same capability has the same numerical code across different terminals.

[0023] Based on the device-side security capability vector, different capabilities are linearly combined and weighted. When comparing operational observations, the deviation of key capabilities is highlighted. For example, a device-side security capability vector is assigned to each terminal. The corresponding components are discrete capability items such as cryptographic algorithm support, presence of a secure chip, and secure storage capacity, and each component is assigned a set of weight vectors. Then calculate the total ability score: ; Among them: Equipment-side security capability vector : No. Numerical descriptions of each terminal across various security capability dimensions, with each component taking non-negative integer values; weight vector. The relative weight of each capability dimension in the overall score, each component is a non-negative real number, and their sum can be normalized as needed; Comprehensive ability score : No. Each terminal's security capability score, calculated based on equipment-side information at the time of manufacture, is a non-negative number; Terminal Serial Number The serial number of the terminal in the terminal set is a positive integer used to uniquely identify a power consumption information collection terminal within a system. By vectorizing and weighting them, complex security capability descriptions can be transformed into fixed-dimensional structured data without losing key details, facilitating the execution of arithmetic operations on observation results, and enabling subsequent hierarchical management of terminals based on capabilities.

[0024] After acquiring the security capability vector from the device side, the terminal continuously collects security capability information from the operational observation side during both trial and formal operation phases to reflect the actual situation of the terminal in the field. Specifically, once the terminal enters the secure access zone and establishes a basic communication link, the capability acquisition component will issue a set of security capability self-check instructions to the terminal step by step according to a preset test sequence. For example, the terminal may encrypt and decrypt a test message according to different cryptographic algorithms and key lengths, and record the calculation time and correctness of the results reported by the terminal; verify whether the terminal has completed firmware integrity verification by using a test firmware header file with a forged signature mark; and statistically analyze the number of abnormal retransmissions, disconnections, and port responses in the terminal communication session within a certain time limit.

[0025] Based on these test results and operational statistics, a security capability vector for the terminal on the observation side is constructed. Each component corresponds to the pass rate and performance level of different test items, and is combined with the equipment-side security capability vector. The capability deviation vector is calculated as follows: ; Wherein: Observation-side security capability vector : No. Each terminal in time The safety capability description is based on on-site testing and operational statistics, with each component being a real number; the equipment-side safety capability vector. Consistent with the aforementioned definition; Capability Deviation Vector : No. Each terminal in time The deviation of the observation capability relative to the equipment capability; each component can be positive, zero, or negative; terminal number. Consistent with the aforementioned meaning; time parameter : A non-negative integer relative to the discrete time scale of system startup.

[0026] By applying a weighted sum of the capability deviation vector using the 1-norm and the infinity norm, a scalar of the deviation magnitude can be obtained, facilitating the rapid identification of terminals with larger deviations during subsequent state segmentation. The introduction of capability deviation transforms the system from static information on the device side to a distinction between theoretical capabilities and field performance during subsequent state segmentation, making it particularly suitable for terminals operating in high-temperature, high-humidity, or electromagnetic interference environments for extended periods.

[0027] Based on the aforementioned capability deviation modeling, we further combine terminal operation status information to extract comprehensive security status features, and map the capability features and status features together into a unified graph structure data.

[0028] First, establish an operational status record chain for each terminal, recording events such as new installation acceptance, access debugging, commissioning, parameter modification, firmware upgrade, fault alarm, and manual intervention in chronological order, and assigning each event a type number and severity level.

[0029] Based on this event information, a terminal operational status feature vector is generated at each time scale, incorporating indicators such as operational stage, recent anomaly frequency, and the interval between the most recent high-risk operation and the current time into a unified description. To facilitate the use of these status features in subsequent processing, the comprehensive security status feature vector can be... Defined as: ; Among them: Comprehensive safety status feature vector : No. Each terminal in time The comprehensive safety status description at that time includes four components; comprehensive capability score. Consistent with the aforementioned definition; deviation magnitude scalar In time The overall deviation of the capability deviation vector is a non-negative real number; operational reliability index In time The combined values ​​of operational quality indicators such as terminal data collection success rate and number of disconnections within the previous statistical window are real numbers between 0 and 1; event impact indicators In time The impact intensity of the most recent high-risk maintenance operation or critical alarm event on the terminal's security status is a non-negative real number; Terminal ID Consistent with the aforementioned meaning, it is used to establish a mapping between capability characteristics and state characteristics; time parameter Consistent with the aforementioned meaning, it is used to ensure that state characteristics at different time scales can be compared and analyzed in chronological order.

[0030] This allows us to simultaneously characterize the terminal's device-side capabilities, field deviations, operational quality, and event impacts within a unified data structure, laying the foundation for the subsequent construction of a terminal security capability and status graph.

[0031] After forming the comprehensive security status feature vector, with the terminal as the node, each node in the graph structure is bound with attributes such as the device-side security capability vector, the observation-side security capability vector, the capability deviation vector, and the comprehensive security status feature vector. Edges between nodes are constructed based on the electrical connection relationship, communication topology relationship, and manufacturer origin relationship between the terminals.

[0032] For example, establishing adjacency relationships between terminals downstream of the same transformer and sharing the same concentrator, marking manufacturer-related edges on terminals supplied by the same manufacturer in the same batch, and adding state-similar edges on terminals in the same operational stage, will create a terminal security capability and state graph that includes the capabilities and states of individual terminals and shows the physical connections, communication paths, and supply chain connections between terminals. This will provide a basis for subsequent structured analysis such as cluster-based state division, differentiated access, and key strategies.

[0033] Step 2: In Step 1, we already have a terminal security capability and state graph containing many terminal nodes, capability nodes, and state nodes, and we have given a comprehensive security state feature vector for each terminal.

[0034] Without further aggregation, directly configuring access and key policies at the terminal level would lead to problems such as a large number of configuration items, complex maintenance, and difficulty in comprehensively understanding the system's security posture. Therefore, by quantifying the security state differences between terminals in a unified feature space, terminals with similar capability deviations, operational reliability, and event impact characteristics are segmented into several state clusters. Subsequently, policies can be configured based on these state clusters. First, the comprehensive security state feature vector output in step one is used to quantify the state differences between terminals, resulting in a difference matrix between terminals. Second, using preset clustering rules, terminals with small differences and similar characteristics are grouped into the same candidate cluster. Then, combining operational phase status markers and maintenance records, the candidate clusters are semantically labeled and named as stable operational clusters, change observation clusters, anomaly observation clusters, and controlled terminal clusters, etc., to give them specific meanings. These are then written into the terminal security capability and state graph, providing a grouping basis for subsequent access and key policy configurations.

[0035] Using the comprehensive security state feature vector obtained in step one as input, the state difference degree between terminals is calculated. If the... Each terminal in time The comprehensive safety state feature vector at time t is Then, each component is defined and given its meaning in step one; if the state difference between any two terminals is the sum of weighted absolute differences, then if it is the state difference between two terminals: ; Wherein: State difference degree : No. The terminal and the first Each terminal in time The degree of difference in overall security status at any given time, a non-negative real number; number of feature dimensions. The number of components in the comprehensive safety status feature vector is a positive integer, corresponding to multiple dimensions such as capability score, deviation range, operational reliability, and event impact; weighting coefficients. : No. The weights of each feature component in the difference calculation are non-negative real numbers. Eigencomponents : No. Each terminal in time The first moment of the comprehensive safety state feature vector Each component is a real number; the characteristic component : No. Each terminal in time The first moment of the comprehensive safety state feature vector Each component is a real number; terminal number Terminal number Positive integers; time parameters A non-negative integer, indicating the time when the state difference is calculated.

[0036] By assigning different weighting coefficients to different characteristic components, we can strengthen our focus on capacity deviation and event impact in the difference calculation, while appropriately reducing the sensitivity to short-term operational fluctuations, making the state cluster division more in line with the safety management priorities of power business.

[0037] After calculating the state dissimilarity between all terminal pairs, a pre-defined clustering process is performed based on the dissimilarity matrix. A threshold-based merging clustering rule is adopted: for any terminal, the first set of terminals whose dissimilarity does not exceed a given threshold is selected to form an initial candidate cluster; subsequently, for any two terminals within a candidate cluster, the dissimilarity is further checked to see if it is within the threshold range. If any individual terminal has a dissimilarity exceeding the threshold compared to the majority of terminals in the cluster, that terminal is separated to form a new candidate cluster. This merging and splitting operation is performed iteratively until the dissimilarity between terminals within all candidate clusters is within an acceptable range. The resulting candidate clusters are compact in the feature space, facilitating subsequent semantic annotation by combining state labels.

[0038] In practice, the construction of state difference degree compresses the multi-dimensional comprehensive security state feature vector into a scalar that is easy to compare, so that the state differences between terminals can be reflected by a single numerical value. Based on this, the candidate cluster construction automatically merges the originally isolated terminal nodes according to state similarity, laying the foundation for subsequent cluster-based policy configuration. The aggregation method based on state difference degree is closer to the current security performance of the terminal, which is conducive to the centralized identification of potentially risky terminals from a limited number of state clusters.

[0039] After the candidate clusters are formed, they are not directly used as the final state clusters. Instead, the candidate clusters are semantically labeled by combining the terminal running status identifier and recent operation and maintenance records, so that each cluster corresponds to a clear security management meaning.

[0040] Therefore, we first need to statistically analyze the distribution of terminal operating status within each candidate cluster, including the proportion of terminals in the running state, the change observation state, and the abnormal observation state, and then statistically analyze the number of high-risk operation and maintenance operations and the number of serious alarms for all terminals within the cluster in the recent period.

[0041] Secondly, candidate clusters are set to the safe state cluster type according to semantic rules. For example, if most terminals in a candidate cluster have been running for a long time and there are few high-risk operation and maintenance operations and serious alarms, it is set as a stable operation cluster; if a candidate cluster has a large number of operations that have just undergone firmware upgrades, important parameter changes, etc., it is set as a change observation cluster; if multiple terminals in a candidate cluster generate multiple authentication failures, communication anomalies and security alarms in a short period of time, it is set as an anomaly observation cluster; if a candidate cluster has remote power-off or power-on control operations, it is marked with a control-related attribute after the above states, and set as a control-related stable operation cluster or a control-related observation cluster, etc.

[0042] As an example, after completing the candidate cluster division, a power supply company automatically generates a status statistics report for each candidate cluster. Engineers can view the number of terminals, operational status distribution, and recent firmware upgrades, batch parameter distributions, and security alarm counts for a particular candidate cluster through an interface. Based on predefined semantic rules, they can confirm whether the cluster is in a stable operational state or a change-observation state. This annotation process can be assisted by the system and reviewed by engineers when necessary. After semantic annotation, the status cluster category is written into the terminal security capability and status graph, associating terminal nodes with their respective status cluster types, preparing for subsequent configuration of different levels of access policies and key policies for status clusters.

[0043] In this way, the candidate cluster is transformed from a set of similar features into a state cluster with security implications. Each state cluster is mathematically related and can be directly understood and managed. Subsequent access strategies can apply different levels of authentication and constraints to different clusters. Control terminals can also be controlled separately in subsequent key strategies, thereby improving the protection capabilities for controlled terminals.

[0044] Furthermore, after state cluster segmentation and semantic annotation, configuring access templates and key policies for each terminal individually would not only be extremely labor-intensive but also prone to inconsistencies. By establishing a mapping relationship between the obtained state cluster characteristics and the access template and key cluster libraries, each state cluster has a corresponding set of access and key policies. This allows for direct invocation of the appropriate policy based on the terminal's state cluster during terminal access and operation, reducing human configuration errors and ensuring that policies adjust as a whole with changes in state clusters.

[0045] First, a cluster-level security index is calculated based on the comprehensive characteristics of each state cluster (such as capability deviation level, event impact level, and control-related attributes). Then, a suitable access template type is selected from the access template library based on this index. Next, on the key management side, one or more key clusters are assigned to each state cluster, and the key validity period and rotation frequency are determined based on the cluster-level security index and control-related attributes. Finally, a correspondence between state clusters, access templates, and key clusters is formed, and this relationship is written into a policy mapping table that can be invoked in steps three and four.

[0046] Specifically, a cluster-level security index is calculated for each state cluster to reflect the overall deviation and event impact of the cluster, and based on this, access templates with different complexities and authentication strengths are selected from the access template library.

[0047] Assume the first Each state cluster contains several terminals. Based on the deviation magnitude scalar and event impact index of the terminals within the cluster, the average deviation and average event impact value within the cluster are calculated, and a cluster-level security level index is constructed. ; Among them: Cluster-level security level indicators : No. The overall safety level of a state cluster at the current moment, a non-negative real number; weighting coefficients. The weight of the deviation magnitude in the cluster-level security calculation is a non-negative real number; the weighting coefficient. The weight of the event impact in the calculation of cluster-level security level is a non-negative real number; average deviation : No. The average value of the deviation magnitude scalar of all terminals within a state cluster within the current statistical window is a non-negative real number; the average event shock... : No. The average event impact index of all terminals within a state cluster within the current statistical window is a non-negative real number; the state cluster number is... : A positive integer used to identify different state clusters.

[0048] By adjusting the weighting coefficients and During actual deployment, the impact of capability deviations or incidents can be emphasized based on the enterprise's security strategy; after calculating the cluster-level security level index, different ranges are assigned according to preset intervals. Mapped to different template types in the access template library. For example, when When the threshold is below the first threshold, a basic access template is selected, which primarily uses single-time authentication and regular session key negotiation; when... When the threshold is between the first and second thresholds, an enhanced access template is selected, which adds an integrity verification or dynamic password check in addition to basic authentication; when If the threshold is higher than the second threshold, or if the state cluster has a control-related attribute marker, a strong protection access template is selected. This template uses a combination of multi-step identity verification and a stronger encryption algorithm in the authentication process. For control-related state clusters, the system can also add an additional confirmation step for control commands in the access template, such as requiring the terminal to return a multi-field confirmation message before executing the control command.

[0049] In use, the selection of access templates no longer relies on manual judgment one by one, but is driven by the characteristics of state clusters and cluster-level security indicators. Stable clusters can use access templates with moderate complexity and reasonable resource consumption to avoid imposing an excessive authentication burden on a large number of normal terminals; while clusters with large deviations or frequent event impacts are automatically bound to more stringent access templates to achieve coordination between access procedures and state division.

[0050] Furthermore, after completing the access template configuration, on the key management side, a corresponding key cluster is assigned to each state cluster, and the key validity period and rotation rhythm are determined according to the cluster-level security level indicators.

[0051] To directly link the risk level of a state cluster to the key lifecycle, the system can use the aforementioned cluster-level security level indicators. Calculate the key rotation period for this cluster: ; Among them: key rotation cycle : No. The rotation time interval for each state cluster corresponds to a key cluster, a positive real number; the maximum rotation period. At the lowest level of security (i.e. The longest allowed key rotation interval (approaching zero), which is a positive real number; security impact coefficient. : The strength of the impact of cluster-level security level indicators on the rotation cycle, a non-negative real number; Cluster-level security level indicators Consistent with the previous definition, a non-negative real number; That is, state cluster risk index Cluster-level security level indicators For the same quantity, the state cluster number Consistent with the aforementioned meaning, it is used to uniquely identify state clusters.

[0052] Therefore, when the cluster-level security level of a state cluster is low, the denominator is close to 1, and the rotation period is close to the maximum rotation period; when the cluster-level security level increases, the denominator increases, and the rotation period is shortened accordingly, thereby enabling more frequent key rotation for high-risk state clusters.

[0053] Furthermore, based on the control-related attributes of the state cluster, the key cluster can be further differentiated into acquisition service keys and control service keys. An independent control key cluster can be configured for the control-related state cluster, and a shorter rotation cycle can be adopted for the control key cluster than for the acquisition key cluster. In addition, for state clusters that have just recovered from a change observation state to a stable operational state, a medium rotation cycle can be used during a certain transition period, and then gradually transitioned to the same rotation cycle as other stable operational state clusters, in order to reduce the operational and maintenance pressure caused by frequent key changes in a short period.

[0054] In practice, key policies are no longer statically linked to terminals or lines, but are instead bound to state clusters and cluster-level security indicators. The key lifecycle corresponds to the actual security indicators of the terminal. State-driven key rotation can be adopted without affecting the basic framework of the key management system, allowing key resources and operational efforts to be invested in higher-risk state clusters, effectively improving the overall security coverage and resource utilization efficiency.

[0055] Step 3: If a unified handshake process and unified key negotiation method that are unrelated to the state cluster are still used during the actual access process of the terminal, the mapping relationship between the state cluster and the key cluster established in the first two steps will be difficult to play its role. The stable cluster and the abnormal observation cluster will receive the same level of protection during access, and the controlled terminal and the ordinary collection terminal will also be difficult to distinguish on the authentication link.

[0056] After receiving an access request from a terminal, the access control unit first retrieves the comprehensive security status feature vector corresponding to the terminal from the terminal's security capability and status graph. This process determines the state cluster number to which the terminal was assigned in step two; then, based on the state cluster number, the associated access template and key cluster number are found; subsequently, based on the handshake sequence and cryptographic algorithm combination in the access template, multiple rounds of challenge-response and session key derivation are completed; finally, a security context token is constructed by combining the terminal number, state cluster number, key cluster number, and cluster-level security level indicators, and is sent to the terminal and the internal secure access system to identify the security attributes of the terminal's current session.

[0057] The secure access control process requires associating the terminal number with the state cluster number. When the... Each terminal in time After sending an access request, the access control process will read the terminal identifier from the terminal message, locate the terminal node in the terminal security capability and state graph, and read the latest comprehensive security state feature vector of the terminal. and state cluster number .

[0058] State cluster number This is the result of state cluster partitioning and semantic annotation in step two, and it has been correlated with a specific state cluster and cluster-level security level index. Establish the corresponding relationship. The access control process obtains... Then, the access template identifier corresponding to the state cluster is looked up in the state cluster to access template mapping table, and the key cluster number corresponding to the state cluster is looked up in the state cluster to key cluster mapping table. And bind these two numbers to the control context of this terminal's current access session.

[0059] Therefore, for terminals running stable state clusters, the access template typically includes one two-way authentication and one session key negotiation, with the cryptographic algorithm and key length matching the security capabilities of the device. For terminals in change observation state clusters or abnormal observation state clusters, the access template includes firmware integrity challenge messages or capability retest messages, while limiting the number of authentication failures that can be tolerated. For state clusters marked with control attributes, the access template performs additional authentication on the control channel.

[0060] Key cluster number This selection ensures that the terminal uses its corresponding group key and personal key during session key derivation, avoiding the use of key materials from other state clusters. During use, a clear and close binding relationship is established between the terminal's state cluster and the specific access session. This transforms the state cluster from a static classification result into a crucial parameter directly determining session layer authentication strength and key source. The technical benefits are: terminals operating in stable clusters can authenticate access to state clusters with lower overhead, while terminals in high-risk or controlled state clusters undergo stricter checks and more effective key control during the access phase.

[0061] After completing the access template selection and key cluster binding, the access control flow begins constructing a security context token. The security context token needs to carry the terminal number, state cluster number, key cluster number, and a digest of the cluster-level security level within a structured object, so that the security attributes of the terminal's current session can be determined with a single query during subsequent business interactions.

[0062] Therefore, the security context token can be represented as a vector as follows: ; Where: security context token vector : No. Each terminal in time The security context corresponding to the access session at any given time contains four components: terminal number. A positive integer used to uniquely identify the terminal; state cluster number. Positive integer: The terminal in time The state cluster type at any given time is derived from the state cluster partitioning result in step two. Key cluster number : is a positive integer, in time The key cluster number that the terminal should use at that time; and All of these indicate the terminal The cluster number belonging to a given state at a given moment; cluster-level security level index. Non-negative real numbers, state clusters The overall security level at the current moment is used to further restrict the service permissions of this terminal during the operational phase; time parameters. : A non-negative integer used to identify the time when this token was generated.

[0063] Once the security context token is constructed, the access control process securely distributes a copy to the terminal and stores a corresponding record within the secure access system. Every service message sent by the terminal during this session must carry this token. When the secure access system receives a service message, it verifies that the message indeed originates from an authenticated and valid session by checking if the token content matches the local record.

[0064] The security context token can also be supplemented with additional fields such as session start and end time and maximum allowed idle time, as needed for the project, as long as the terminal number, state cluster number and key cluster number are clearly and uniquely encoded in the token.

[0065] In use, the security context token becomes the concrete carrier connecting the terminal, state cluster, and key cluster, enabling all service messages in subsequent operational phases to obtain the required security context information after a single token verification. This reduces the overhead of repeatedly querying the state cluster and key cluster during operation, while ensuring that each service operation is explicitly constrained within the known state cluster and key cluster.

[0066] After a terminal successfully connects and obtains a security context token, if the operational phase relies solely on basic authentication without considering state cluster characteristics and cluster-level security indicators, terminals in high-risk state clusters may still perform the same business operations as low-risk terminals, and terminals in controlled state clusters may continue to accept control commands even after their state deteriorates. During the operational phase, whenever a terminal initiates a meter reading, fee control, or control request, the secure access system checks the operation type and parameters of the request item by item based on the state cluster number, key cluster number, and cluster-level security indicators in the security context token, combined with a preset permission mapping function; simultaneously, authentication failures, permission denials, and abnormal behaviors are recorded as security events, and event impact indicators are calculated. The updated values ​​reflect these events back to the terminal's overall security status characteristics, providing a basis for subsequent state cluster adjustments.

[0067] Based on security context tokens, runtime permission determination and business message processing are performed, clearly distinguishing between stable runtime state clusters, change observation state clusters, and anomaly observation state clusters in terms of acceptable business types; and security events generated during the runtime, such as authentication failures, permission denials, abnormal message formats, and frequent control requests, are aggregated into event impact indicators according to preset rules. This affects the overall security state feature vector. This makes the cluster-level security level index in step two... The abnormal situations that occurred during the operation phase can be reflected in the next round of calculation.

[0068] During operation, the secure access system performs permission checks on every service request from a terminal. Specifically, when the first... Each terminal in time When a business message containing an operation type is sent, the execution control flow first extracts the security context token vector carried with the message. The validity of the token is then confirmed in the local record based on the terminal number and state cluster number; subsequently, the state cluster number is read from the token. Cluster-level security level indicators Through pre-established permission mapping functions Calculate the service permission vector of this terminal at the current moment: ; Wherein: Business permission vector : No. Each terminal in time The permission configuration for various business operations that are allowed to be executed at all times, with each component being a binary value or a multi-level permission code; Permission mapping function : A function that maps state cluster numbers and cluster-level security level indicators to business permission vectors. Its specific form can be implemented during project deployment by looking up tables or combining rules. It is used to classify terminals under different state clusters and different security levels into different permission configuration levels. Let each state cluster There is a cluster type encoding ,For example Indicates a stable cluster in operation. Indicates running the observation cluster, This represents an abnormal observation cluster or a high-risk cluster requiring control. Assume the business permission vector is three-dimensional: ; Meter reading permission flag, retrieve or . : Parameter read / write permission flag, retrieve , Or multi-level integers; : Control command permission flags, retrieve or .

[0069] Define two risk thresholds Then, the segmented form can be given: ; Cluster type encoding : Integer, indicating the semantic category of the cluster to which the terminal belongs.

[0070] : For a pre-configured permission template vector, such as Allow full-service Prohibited from control Meter reading is permitted only.

[0071] This format explicitly lists the correspondence between the input (state cluster number encoded by cluster type, cluster-level security level) and the output (permission vector), with specific permission templates and thresholds configured by the security policy.

[0072] State cluster number Consistent with the aforementioned definition, this indicates the state cluster type to which the terminal belongs; Cluster-level security level indicators Consistent with the aforementioned definition; Terminal number With time parameters Consistent with the meaning mentioned above.

[0073] Permission mapping function Number the state clusters and state cluster risk indicators Mapping to business permission vector For example, we can agree on the following: when Corresponding to a stable cluster and When it is below the first threshold, Meter reading and parameter reading are allowed, but control is not allowed; when Corresponding to the observed cluster and When the meter is in the middle range, meter reading and minor parameter modifications are allowed, but control operations require additional manual confirmation; when... Corresponding anomaly observation cluster or When the risk threshold is exceeded, only meter reading is allowed; parameter modification and control are not permitted.

[0074] The execution control process obtains the business permission vector. Then, it is compared with the operation type code requested in the current business message. For example, it is determined whether the current request is a power outage command, a rate parameter modification, or simply a meter reading command. When the request type exceeds the range allowed by the permission vector, the operation control process immediately rejects the request, records the event as a permission rejection event, and feeds it back to the terminal. When the request type is within the allowed range, the integrity verification and replay protection verification of the message content continue. Only when all verifications pass is the request forwarded to the electricity information collection master station or downstream equipment.

[0075] In one specific embodiment, after multiple authentication failures, a terminal in an abnormal observation cluster within a certain distribution area has had its cluster number and cluster-level security level index updated, resulting in the control command component in the service permission vector being set to prohibited. Subsequently, when a power-off command message initiated by this terminal enters the secure access system, although the token is still valid, the service permission vector calculated by the permission mapping function does not allow this type of operation. The execution control flow accordingly refuses to forward the control command and records this behavior as a permission denial event. Simultaneously, the meter reading request initiated by the terminal is still within the allowed range, so it can continue to be forwarded and the meter reading result can be returned. When the maintenance personnel view the permission mapping results, they can intuitively see that the terminal is in an abnormal observation cluster and is prohibited from performing control operations, thus enabling targeted on-site troubleshooting.

[0076] In practice, service permissions during the runtime phase are no longer determined by fixed rules, but rather by the state cluster number and cluster-level security level indicators. This allows the state division and key policy during the access phase to be extended to the decision-making process for each service message. Even if a terminal in a high-risk state cluster passes access authentication, it can only perform limited services within the scope permitted by the permission vector. Terminals in controlled state clusters will have their control operation scope automatically restricted when their state deteriorates, reducing the impact of misoperations or malicious operations.

[0077] Furthermore, the operation control process aggregates various safety events generated during the operation phase into event impact indicators according to preset rules, thereby updating the comprehensive safety status feature vector. Event impact component .

[0078] Specifically, a weight coefficient is assigned to each type of security event. For example, different weights are set for authentication failure events, permission denial events, suspected replay events, and abnormal message format events.

[0079] For the Each terminal, in time At any given moment, for each type of event Record an event indicator When this type of event is detected by the terminal at that moment, The value is 1 if it is not 0 otherwise. At the end of each time step, update the event impact metric. for: ; Among them: event impact indicators : No. Each terminal in time The event impact component at time t, a non-negative real number; attenuation coefficient. The percentage of historical event impact indicators retained relative to current event impact indicators, with values ​​ranging from... and Between, when near Historical events have a longer retention period, when The impact of historical events decays more rapidly at lower levels. Previous moment event impact index : No. Each terminal in time The event impact component at time, a non-negative real number; a set of event types. The system monitors a set of security event types, including authentication failures, permission denials, suspected replays, and abnormal message formats. Each element in the set is a finite number of event type identifiers; event weight. Event Type The contribution weight to the event impact indicator, a non-negative real number; event indicator quantity. : No. Each terminal in time Does the event type occur at any given time? When it occurs, the value is taken as When it does not occur, the value is taken as Terminal Number With time parameters Consistent with the meaning mentioned above.

[0080] Updated event impact metrics It will be written back to the comprehensive security state feature vector The corresponding components are then used to calculate the cluster-level security index in the next step, step two. This is directly adopted when dividing state clusters. For example, when a terminal triggers multiple permission denial and authentication failure events in a short period of time, the events with higher event weights will... The rapid increase in size will cause the terminal to be assigned to the abnormal observation state cluster in the next round of state cluster re-division, and the cluster-level security level index of its state cluster will also increase accordingly, which will lead to access template enhancement and key rotation cycle shortening.

[0081] In practice, security events during the runtime phase are no longer isolated log entries, but are structured and written back to the terminal's comprehensive security status characteristics in the form of event impact indicators. This allows the state cluster division and key policy calculation in step two to reflect the actual risk situation during the runtime phase. The system can gradually adjust the terminal's state clusters and access strength based on the objectively recorded event sequences, enabling the security policy to dynamically converge to a more reasonable configuration as the runtime process progresses.

[0082] Step 4: If maintenance operations are still recorded via telephone notification or simple work orders, the secure access system cannot link a specific firmware upgrade or key reset to a particular terminal state cluster or risk indicators for that terminal state cluster. And the event impact values ​​of which terminal state clusters There is a direct correspondence, making it even more difficult to make targeted adjustments to the terminal status and key policy based on the operation and maintenance records.

[0083] Therefore, when an operation and maintenance (O&M) request is submitted, a unified ticket generation process is needed to encapsulate the O&M personnel's identity, the O&M terminal, the target terminal range, the set of O&M operation types, the expected status adjustment rules, and the time window into a structured O&M ticket object. When an O&M personnel initiates a high-risk O&M request in the O&M management system, for example, requesting a firmware upgrade for a batch of terminals in a certain area under observation, the O&M management system first requires the O&M personnel to select their own identity and the O&M terminal to be used in the interface, specifying the set of target terminals involved in this operation.

[0084] Based on the terminal IDs in the target terminal set, retrieve the current state cluster ID and state cluster risk indicators for each terminal from the terminal security capability and state graph. and event impact value The operation and maintenance management system groups the target terminal set according to status cluster numbers, enabling the tickets to explicitly distinguish between different categories such as the stable state cluster terminal set and the observation state cluster terminal set. Subsequently, operation and maintenance personnel select the operation and maintenance operation types to be performed one by one in the interface, such as updating the firmware version from V1 to V2, issuing new rate parameters, triggering key reset, etc. Each operation type has a pre-registered sensitivity level in the system, which is used to determine the allowed state adjustment range later.

[0085] When in use, each high-risk operation and maintenance requirement will become an operation and maintenance ticket object. The operation and maintenance ticket shows the operation and maintenance personnel, operation and maintenance terminals, target terminal set, operation type set and expected status adjustment rules. The operation and maintenance ticket is the connector between operation and maintenance requirements and terminal status sets, so that the subsequent secure access system can check whether the personnel, terminals and operations match based on the ticket before accessing specific instructions, avoiding the dangers caused by verbal instructions or unstructured records.

[0086] Furthermore, after generating the maintenance ticket containing the target terminal set and the operation type set, it is also necessary to determine the maintenance instruction window corresponding to this ticket, that is, the time range within which the maintenance operation in the ticket is allowed to be executed, and under what state cluster risk level the window length should be tightened.

[0087] If maintenance tickets are valid indefinitely once issued, even if the target terminal status cluster risk indicators... and event impact value If significant changes occur subsequently, older tickets may still support high-risk operations, weakening the role of previous steps in state classification and operational control. Therefore, it is necessary to define a ticket risk coefficient and automatically calculate the length of the operation and maintenance instruction window accordingly, so that tickets corresponding to high-risk state clusters and terminals affected by high events receive shorter instruction windows.

[0088] When an operation and maintenance management system approves a ticket, it determines the target terminal set and creation time based on the ticket. Calculate a ticket risk coefficient, and then calculate the maintenance instruction window length based on this coefficient. The ticket risk coefficient for a specific maintenance ticket can be defined. This refers to a combination of risk indicators and event impact values ​​for state clusters within the target terminal set, for example: ; Redefine the length of the operation and maintenance command window for: ; Among them, the risk coefficient of bills Number is The overall risk level of the maintenance invoice at the time of creation, a non-negative real number; weighting coefficient. : The weight of the state cluster risk indicator on the bill risk coefficient, a non-negative real number; weight coefficient The impact weight of the event impact value on the risk coefficient of the bill is a non-negative real number used to reflect the cumulative impact of recent abnormal events. Maximum risk item The set of target terminals involved in the bill Risk indicators of all terminal state clusters The maximum value is used to capture the risk of the most sensitive terminals; target terminal set The set of terminal numbers involved in this ticket, and the size of the set. A positive integer; event impact value :terminal At the time of bill creation The event impact value is derived from the cumulative calculation of the running events in step three, and is a non-negative real number; Invoice creation time : The time scale for issuing maintenance tickets, which is a non-negative real number; : The length of the maintenance instruction window. Number is The ticket specifies the duration for which maintenance instructions can be executed, a positive real number; the base window length. : The longest maintenance window length allowed when the risk coefficient of the bill approaches zero, which is a positive real number.

[0089] When in use, maintenance tickets no longer have a static or indefinitely extended validity period, but are instead combined with state cluster risk indicators. Event Impact Value Get a specific operation and maintenance command window length This ensures that operational and maintenance activities are always performed within a timeframe that matches the current risk level. In scenarios involving a cluster of high-risk terminals or terminals experiencing frequent anomalies, the risk coefficient of the invoice... Increase the length of the operation and maintenance command window. This shortens the timeframe, thereby reducing the risk of exposing highly sensitive operational entry points over extended periods. For lower-risk terminal sets, operational personnel can complete batch operations within a more flexible timeframe, balancing security and work efficiency.

[0090] Furthermore, when a single maintenance instruction arrives at the secure access system, it needs to be compared with the maintenance ticket, security context token, and terminal state cluster information to prevent unauthorized maintenance personnel, unauthorized maintenance terminals, objects outside the target terminal range, or instructions exceeding the allowed operation set from being executed. At the same time, at the end of maintenance, how to update the terminal security status and key cluster configuration according to the pre-set state adjustment rules in the ticket and the actual execution results, so that maintenance behavior leaves traceable traces in the state graph and cryptographic policy.

[0091] If maintenance tickets are only checked once during generation and approval, and not compared with each maintenance instruction individually during execution, problems may arise such as the ticket holder using the ticket on other terminals, executing instructions outside the ticket window, or performing operations on maintenance terminals without authorization, thus weakening the security value of the ticket mechanism. Therefore, when maintenance instructions enter the secure access system, it is necessary to strictly compare five elements—maintenance personnel identity, maintenance terminal identity, target terminal identifier, specific operation type, and current time—with the ticket content.

[0092] When an operations and maintenance (O&M) personnel issue an O&M command on an O&M terminal, such as selecting a terminal to perform a firmware upgrade, the O&M terminal will include the current user's login identity, the O&M terminal device identifier, the target terminal identifier, the operation type identifier, and the associated O&M ticket number in the command message. After receiving the command message, the secure access system first searches for the ticket record based on the ticket number, then compares the O&M personnel identifier carried in the message with the O&M personnel identifier recorded in the ticket to confirm that the command initiator is indeed the ticket issuer. Subsequently, the system compares the O&M terminal identifier in the message with the O&M terminal identifier in the ticket record to prevent the ticket from being copied and used on other terminals. Next, the system checks whether the target terminal identifier belongs to the target terminal set of the ticket record, and adjusts the ticket risk coefficient accordingly. Corresponding maintenance command window length Within this timeframe, the system further verifies whether the current time falls between the start and end times of the ticket. Finally, based on the operation type identifier and the set of operation types in the ticket, the system determines whether this instruction falls within the permitted operation range of the ticket. If any of the above comparisons fails, the secure access system will refuse to execute the maintenance instruction and record an unauthorized ticket usage attempt event.

[0093] In practice, each maintenance command must undergo a series of comparisons—including maintenance personnel, maintenance terminal, ticket number, target terminal, operation type, and time window—before it can enter the specific equipment control process. The ticket content is transformed from a document-based record into a precondition for execution, ensuring that constraints in ticket approval are truly implemented at the command execution level and preventing tickets from being misappropriated or expired.

[0094] After executing the operation and maintenance instructions, it is also necessary to update the terminal node status in the terminal security capability and status graph and the key cluster configuration in the status cluster according to the pre-agreed status adjustment rules in the operation and maintenance ticket and the actual execution results.

[0095] Firmware upgrades, parameter changes, and key resets can alter the security characteristics of a terminal. If this change is not reflected in the state graph and key policy, subsequent steps two and three, when dividing state clusters and determining running permissions, will not accurately reflect the actual security status of the terminal.

[0096] Once all or part of the maintenance operations listed in a maintenance ticket have been executed, the secure access system updates the corresponding terminal's runtime event record based on the execution result of each instruction.

[0097] For successfully executed firmware upgrade commands, the system updates the firmware version number field of the terminal node to the new version number and adds a firmware upgrade completion event to the status record. For successfully executed key reset commands, the system updates the key cluster version number associated with the terminal in the key management unit and records a key reset completion event in the status graph. Subsequently, according to the pre-agreed status adjustment rules in the ticket, the system migrates terminals that have undergone high-risk operation and maintenance from the original status cluster to a new status cluster. For example, it migrates terminals in the stable operation status cluster to the change observation status cluster and updates the status cluster risk indicator input values ​​for these terminals, so that the status cluster risk indicators in the next round are updated. The calculation can take into account the impact of this operation and maintenance activity.

[0098] In practice, operational actions, terminal states, and key policies all have corresponding update paths. The operational tickets define the state adjustment rules, and the results of operational instructions trigger state transitions and key cluster version updates. Subsequent risks and operational permissions of the state cluster depend on this state information. Firmware upgrades, parameter adjustments, and key resets are no longer just one-off actions; the state graph and key cluster configuration will form a continuous record at the system level, which is beneficial for subsequent operational audits and fault location. As an equivalent method, state transitions can adopt different granularities, such as adding sub-states within a state cluster. Any state change caused by operational operations will be reflected in the state graph and key cluster configuration.

[0099] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0100] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0101] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0102] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0103] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A secure access and trusted authentication system for electricity information collection terminals, characterized in that: include, The system acquires the security capability information of the power consumption information collection terminal from the equipment side and the operation observation side on the security access zone side, compares the two to obtain capability deviation information, and constructs a terminal security capability and status map with the terminal as the node in combination with the current operating status of the terminal. Capability deviation information and operational characteristics are extracted from the terminal security capability and state graph. The terminals are clustered into multiple state clusters. An access template is selected from the template library for each state cluster, and a key cluster corresponding to the state cluster is established. When a terminal initiates an access or service request, it determines the state cluster it belongs to based on the state cluster division, selects the access template and key cluster corresponding to the state cluster to complete authentication and key negotiation, and generates a security context token to identify the terminal's state cluster and key cluster. When performing critical operation and maintenance operations on the terminal, the operation and maintenance management system generates operation and maintenance tickets. The operation and maintenance tickets record the operation and maintenance subject and status adjustment rules. The secure access platform verifies the operation and maintenance instructions based on the operation and maintenance tickets and security context tokens, and updates the graph and corresponding key clusters according to the status adjustment rules after execution.

2. The secure access and trusted authentication system for electricity information collection terminals according to claim 1, characterized in that: Obtaining safety capability information from both the equipment side and the operational monitoring side includes: Before the initial access, the terminal manufacturer shall report the types of cryptographic algorithms supported by the terminal, the security hardware configuration, the local security storage and security log capabilities, and the operation and maintenance interface types through encrypted messages. During the terminal access and operation process, the platform shall issue security capability self-check tasks and collect statistics on algorithm task completion time, accuracy rate, forged signature firmware interception, port open status, and abnormal retransmission and disconnection.

3. The secure access and trusted authentication system for electricity information collection terminals according to claim 2, characterized in that: When constructing the terminal security capability and status map, capability deviation information, the terminal's current new installation status, debugging status, and running status, as well as the maintenance records of the most recent firmware upgrade, parameter modification, and key reset are used as status features associated with terminal nodes in the map. Connections between nodes are established based on the physical wiring relationship, communication topology relationship, and manufacturing unit origin relationship between terminal nodes to support subsequent state cluster division.

4. The secure access and trusted authentication system for electricity information collection terminals according to claim 3, characterized in that: Clustering terminals into multiple state clusters includes: aggregating the comprehensive security status features of terminals according to a preset difference threshold to obtain stable operation state clusters, change observation state clusters, anomaly observation state clusters, and controllable state clusters; and writing the type identifier of each state cluster into the terminal security capability and status map for identification of the state cluster to which the terminal belongs during the access and operation and maintenance phases.

5. The secure access and trusted authentication system for electricity information collection terminals according to claim 4, characterized in that: Selecting an access template from the template library and establishing a corresponding key cluster for each state cluster includes: For stable state clusters, an access template including two-way authentication and session key negotiation is selected. For observation and abnormal state clusters, an access template including integrity verification and capability retesting is selected. For access templates of controlled state clusters, a control command confirmation step is added. In the key management system, a key cluster consisting of a root key, a group key, and a personal key is configured for each state cluster.

6. The secure access and trusted authentication system for electricity information collection terminals according to claim 5, characterized in that: When a terminal initiates an access or service request, a security context token is generated, including: After the terminal completes identity authentication and session key negotiation according to the access template, the secure access platform generates a security context token carrying the terminal identifier, the terminal's state cluster identifier, the key cluster identifier, and the current security state summary field. The token is stored on both the terminal and the secure access platform. Subsequent service packets from the terminal carry the security context token.

7. The secure access and trusted authentication system for electricity information collection terminals according to claim 6, characterized in that: The secure access system determines permissions based on security context tokens and state cluster configurations, including: For meter reading requests, fee control requests, and control commands carrying security context tokens, the status cluster identifier and current security status summary are read respectively. Terminals in the abnormal observation status cluster and the control status cluster are restricted to only perform business operations within their authorized scope. For business requests that exceed the authorized scope, an authorization denial record is generated and written into the terminal security capability and status graph.

8. The secure access and trusted authentication system for electricity information collection terminals according to claim 7, characterized in that: The operation and maintenance tickets generated by the operation and maintenance management system include: Record the identity of the operation and maintenance personnel, the identity of the operation and maintenance terminal device, the target terminal identity set or target status cluster identity, the set of allowed operation and maintenance operation types, the allowed status adjustment range, and the operation and maintenance time window. In the operation and maintenance ticket, reference the security status summary in the terminal security capability and status graph at the corresponding time for pre-constraint and verification when operation and maintenance instructions are issued.

9. The secure access and trusted authentication system for electricity information collection terminals according to claim 8, characterized in that: The secure access platform verifies maintenance instructions based on maintenance tickets and security context tokens, including: When receiving maintenance instructions from the maintenance terminal, the system reads the maintenance personnel's identity, maintenance terminal identifier, target terminal identifier, maintenance operation type, and maintenance ticket number carried in the instruction, compares them with the fields recorded in the maintenance ticket, and checks whether the time is within the maintenance time window. The maintenance instruction is forwarded only if the comparison is consistent and the maintenance ticket is valid.

10. The secure access and trusted authentication system for electricity information collection terminals according to claim 9, characterized in that: After performing maintenance operations, the terminal security capabilities and status graph and corresponding key clusters are updated according to the status adjustment rules. This includes: recording the corresponding maintenance events in the terminal security capabilities and status graph for successfully executed firmware upgrades, parameter modifications and key resets, and migrating the terminal node from its original status cluster to the target status cluster. At the same time, the key cluster identifier referenced by the terminal is switched in the key management system and status change records and policy change records are generated.

Images