Data security and privacy protection methods for power distribution automation systems

Abstract

This invention relates to the field of power distribution automation safety technology and discloses a method for data security and privacy protection in power distribution automation systems. The method includes deploying data sensing probes at the data acquisition end to capture raw data packets in real time; performing deep analysis on the data packets to extract payload content and transmission path features; inputting the payload content into a dynamic masking engine to perform real-time obfuscation processing on specific data segments according to privacy field rules; simultaneously, sending the transmission path features into a security evaluator to calculate a path credibility score; and generating a data block to be transmitted with privacy protection tags and security level identifiers based on the output of the dynamic masking engine and the path credibility score. This invention achieves real-time, refined privacy protection of data at the source and quantitative assessment and labeling of transmission path security risks, improving the data's own security capabilities and the overall proactive protection level of the system.

Description

Technical Field

[0001] This invention relates to the field of power distribution automation safety technology, specifically to methods for data security and privacy protection in power distribution automation systems. Background Technology

[0002] Power distribution automation systems generate and transmit massive amounts of real-time data during operation. This data includes sensitive information such as system operating status, control commands, and user electricity consumption behavior. Currently, the security and privacy protection of this type of data commonly employs static data anonymization or traditional encryption techniques. Static data anonymization is typically performed after the data is stored in a database, a batch processing operation. Traditional encryption techniques focus on establishing a secure tunnel at the communication channel level, encrypting the entire data stream during transmission. These methods treat the security of the data content itself and the security of the data transmission path as two relatively independent aspects.

[0003] Existing technical solutions have shortcomings. Static data masking, due to its post-processing nature, cannot address the risk of data leakage during the real-time data flow from the acquisition end. Furthermore, its coarse-grained masking fails to meet the need for fine-grained protection of specific privacy fields within data packets. Traditional channel encryption, while ensuring the confidentiality of data transmission, completely exposes its content once the channel is breached or the data reaches its destination. Simultaneously, this method cannot assess or record the security of the network path traversed by the data packet itself; the security status of the data content and the transmission path is separated, making subsequent systems unaware of potential risks such as routing hijacking or path eavesdropping encountered during transmission.

[0004] Current technologies lack the capability to provide real-time, granular content protection for data packets in transit at the source of data generation. Furthermore, there is a lack of a mechanism to correlate the secure processing of data content with the security status of its transmission path. This leaves power distribution automation systems without proactive, context-aware protection against data privacy breaches and path-based cyberattacks. Summary of the Invention

[0005] The purpose of this invention is to provide a method for data security and privacy protection in power distribution automation systems, so as to solve the problems mentioned in the background art.

[0006] To achieve the above objectives, the present invention provides a method for data security and privacy protection in a power distribution automation system, the method comprising:

[0007] Deploy data sensing probes at the data acquisition end of the power distribution automation system to capture raw data packets flowing through network nodes in real time;

[0008] Deeply analyze the captured raw data packets to extract the payload content and transmission path characteristics of the data packets;

[0009] The payload content is input into the dynamic masking engine, which performs real-time obfuscation on specific data segments according to predefined privacy field rules.

[0010] At the same time, the transmission path characteristics are fed into the security evaluator to calculate the path credibility score;

[0011] Based on the output of the dynamic masking engine and the path credibility score of the security evaluator, a data block to be transmitted is generated with privacy protection tags and security level identifiers.

[0012] Preferably, the step of inputting the payload content into the dynamic masking engine and performing real-time obfuscation processing on specific data segments according to predefined privacy field rules includes the following steps:

[0013] A privacy field rule base is established, which defines the sensitive data types that need to be protected in the power distribution automation system and their corresponding data format characteristics;

[0014] The dynamic masking engine scans the payload content byte by byte and performs pattern matching with format features in the privacy field rule base;

[0015] When a specific data segment that conforms to the characteristics of a sensitive data format is identified, the built-in obfuscation algorithm is triggered to perform an irreversible transformation on the specific data segment.

[0016] Record the location information of each obfuscated specific data segment in the original payload and generate the corresponding mask metadata.

[0017] Preferably, the step of feeding the transmission path features into the security evaluator and calculating the path credibility score includes the following steps:

[0018] The security evaluator extracts the source address, destination address, sequence of intermediate nodes, and timestamp information from the transmission path characteristics.

[0019] Query the historical path behavior database to obtain historical behavior records of the source address, destination address, and intermediate node sequence;

[0020] Based on historical behavior records, analyze the stability of the path and abnormal access patterns, and combine timestamp information to determine whether the current transmission behavior meets expectations;

[0021] By combining the results of various analyses using a weighted calculation model, a quantitative path credibility score is output.

[0022] Preferably, the steps for generating the data block to be transmitted with privacy protection markers and security level identifiers include:

[0023] The data assembler receives the obfuscated payload content and its mask metadata from the dynamic masking engine;

[0024] The data assembler also receives path credibility scores from the security evaluator;

[0025] The data assembler maps path credibility scores to predefined security level ranges to determine the security level identifier of the data block to be transmitted;

[0026] The obfuscated payload content, mask metadata, and security level identifier are encapsulated, and a privacy protection flag is set in the encapsulation header to form a complete data block to be transmitted.

[0027] Preferably, after forming the data block to be transmitted, the method further includes the following steps:

[0028] Send the data block to be transmitted to the policy enforcement gateway;

[0029] The policy enforcement gateway parses the privacy protection tags and security level identifiers encapsulated in the data blocks to be transmitted;

[0030] Based on the parsing results, the policy enforcement gateway matches the corresponding transmission control policy and encryption policy from the policy library;

[0031] The matched encryption strategy is used to encrypt the data block to be transmitted, forming a ciphertext data block.

[0032] Preferably, the policy execution gateway matches the corresponding transmission control policy and encryption policy from the policy library based on the parsing result. Specific steps include:

[0033] The policy execution gateway has a built-in policy library, which defines the transmission control parameters and encryption algorithm types to be used under different combinations of privacy protection flags and different security level identifiers;

[0034] The policy enforcement gateway uses the privacy protection tag and security level identifier of the data block to be transmitted as joint query conditions;

[0035] Search the policy library to obtain the transmission control policy entries and encryption policy entries that completely match the joint query conditions;

[0036] If no exact match is found, the default transmission control and encryption policies will be used.

[0037] Preferably, the step of encrypting the data block to be transmitted using the matched encryption strategy includes the following steps:

[0038] The encryption engine extracts the encryption algorithm type and key index from the matched encryption policy entries;

[0039] Obtain the corresponding encryption key from the key management service center based on the key index;

[0040] Use the acquired encryption key and the specified encryption algorithm type to perform encryption operations on the entire block of data to be transmitted;

[0041] Generate ciphertext data blocks and attach encryption header information to identify the encryption algorithm and key version.

[0042] Preferably, after generating the ciphertext data block, the method further includes the following steps:

[0043] Send the encrypted data block to the data distribution service;

[0044] The data distribution service maintains a list of authorized recipients and their respective data access permission configuration files;

[0045] The data distribution service filters out authorized recipients with corresponding access permissions based on the security level identifier in the encrypted header information attached to the encrypted data block;

[0046] Multiplexing technology is used to transmit encrypted data blocks simultaneously to all selected authorized recipients.

[0047] Preferably, the data distribution service filters out authorized recipients with corresponding access permissions based on the security level identifier in the encryption header information attached to the encrypted data block. Specific steps include:

[0048] The data distribution service parses the encryption header information of the encrypted data block and extracts the security level identifier from it;

[0049] Read the list of authorized recipients and query the data access permission configuration file for each authorized recipient one by one;

[0050] The extracted security level identifier is compared with the range of security levels allowed in the data access permission configuration file of each authorized recipient;

[0051] Only authorized recipients whose security level identifiers fall within the permitted security level range are retained as valid recipients.

[0052] Preferably, after the data distribution service completes the transmission of the encrypted data block, the method further includes the following steps:

[0053] On the authorized receiver side, the receiving decryption module selects the appropriate decryption key and decryption algorithm based on the encryption header information of the ciphertext data block;

[0054] The receiving end decryption module decrypts the ciphertext data block to recover the data block to be transmitted;

[0055] The receiving end parsing module parses the recovered data block to be transmitted and reads its privacy protection mark and security level identifier;

[0056] Based on the privacy protection flag, decide whether to invoke the data restoration module to perform a reverse restoration operation on the obfuscated data in the payload;

[0057] Finally, the processed data is sent to the business application layer of the power distribution automation system for further processing.

[0058] Compared with the prior art, the beneficial effects of the present invention are:

[0059] By deploying data-aware probes for deep analysis and utilizing a dynamic masking engine, specific privacy fields in data packet payloads can be identified and obfuscated in real time according to predefined rules. This process is completed instantly at the data acquisition end, acting on the data flow as it passes through network nodes, preventing sensitive information from being transmitted in plaintext at any stage of the system. Fine-grained field-level operations ensure a balance between data availability and privacy protection; non-sensitive policy instructions and other data remain intact, while only critical privacy segments are obfuscated. This reduces the risk of privacy leaks due to data packet interception or insider theft, achieving front-end protection throughout the data lifecycle.

[0060] Transmission path characteristics are extracted from data packets and analyzed independently. A security evaluator quantifies and calculates path trustworthiness scores, attaching a security context of its transmission history to each data block. This score, along with obfuscated data content, generates the data block to be transmitted, thus imbuing the data itself with a path security identifier. When subsequent data processing units receive this data block, they can determine the trustworthiness of its source path without additional probing. Based on this identifier, they can implement differentiated security policies, extending security decision-making from the network boundary to the data interior, enhancing the ability to perceive and respond to network layer threats such as path hijacking and man-in-the-middle attacks.

[0061] The dynamic masking engine combines real-time content protection with the security evaluator's quantitative path assessment to generate a unified, self-contained secure data unit. This mechanism changes the traditional model where content protection and transmission security are separated, constructing an integrated correlation between the intrinsic attributes of data and the security status of the external environment. It allows security control to move beyond fixed network boundary policies and permeate every data unit, enabling security policies to dynamically take effect as data flows, thus improving the granularity and proactivity of security protection in power distribution automation systems. Attached Figure Description

[0062] Figure 1 This is a schematic diagram illustrating the working principle of the data security and privacy protection method for the power distribution automation system described in this invention.

[0063] Figure 2 A flowchart for calculating path credibility scores for a security evaluator;

[0064] Figure 3 A flowchart for generating data blocks to be transmitted. Detailed Implementation

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

[0066] Please see Figure 1 This invention provides a data security and privacy protection method for a power distribution automation system. The method includes: deploying a data sensing probe at the data acquisition end of the power distribution automation system, which captures raw data packets flowing through network nodes in real time; performing deep analysis on the captured raw data packets to extract the payload content and transmission path characteristics; inputting the payload content into a dynamic masking engine to perform real-time obfuscation processing on specific data segments according to predefined privacy field rules; simultaneously, sending the transmission path characteristics into a security evaluator to calculate a path credibility score; and generating a data block to be transmitted with privacy protection tags and security level identifiers based on the output of the dynamic masking engine and the path credibility score of the security evaluator.

[0067] Example 1: See Figure 2 In practical implementation, the dynamic masking engine's processing relies on a pre-built privacy field rule base. The core function of this rule base is to precisely define all sensitive data types that need protection within the power distribution automation system, as well as the corresponding data format characteristics. The construction of the privacy field rule base is a systematic process based on in-depth analysis of the communication protocols and data structures of the power distribution automation system. For example, in standard protocols such as IEC 61850, data object names, measured values, timestamps, and device identifiers may all be classified as sensitive information. The privacy field rule base is stored and managed in the form of database tables. Each rule record contains at least a classification identifier for the sensitive data type, a regular expression pattern for identifying that type of data, and an identifier for the obfuscation algorithm to be triggered when a match is successful. The regular expression pattern is designed for the specific representation of sensitive data in the data stream. For example, a 32-bit integer current measurement value may correspond to a binary pattern or a string pattern. These patterns are compiled into regular expressions for efficient matching.

[0068] In its implementation, the dynamic masking engine loads the complete privacy field rule base from persistent storage into memory during startup to ensure extremely high speed for subsequent pattern matching operations. Once the payload content is fed into the dynamic masking engine, it initiates a byte-by-byte scanning process. This byte-by-byte scanning method sequentially processes data streams, starting from the first byte of the payload content and checking each byte in turn. It performs real-time pattern matching between the current checkpoint and its subsequent byte sequence and all loaded format feature regular expressions in the privacy field rule base. The pattern matching algorithm employs an optimized string matching engine, such as an automata-based matching algorithm, to support parallel comparison of multiple regular expression patterns, thereby improving matching efficiency. During the byte-by-byte scanning process, once a continuous byte sequence is found to successfully match a format feature regular expression in the privacy field rule base, the dynamic masking engine determines that it has identified a specific data segment that conforms to the sensitive data format characteristics.

[0069] In practice, once a specific data segment is successfully identified, the dynamic masking engine immediately triggers the built-in obfuscation algorithm associated with that rule. The choice of obfuscation algorithm is determined by the obfuscation algorithm identifier defined in the rule. For example, for data requiring irreversible de-identification, such as device identifiers, a truncated SHA-256 hash algorithm might be used; for numerical measurement data, a randomization algorithm with controlled noise or multiplicative perturbation might be used. The obfuscation algorithm performs an irreversible transformation operation on the specific data segment. Irreversible transformation means that the original sensitive data content cannot be derived from the transformed result data, thus achieving privacy protection while avoiding the privacy leakage risks that may arise from data restoration. The dynamic masking engine ensures that the obfuscation process is performed on a copy of the original payload content to maintain the integrity of the original data for auditing purposes.

[0070] In practice, the dynamic masking engine, while performing obfuscation, simultaneously records the precise location information of each obfuscated data segment within the original payload. This location information typically includes the starting byte offset of the specific data segment within the payload, the segment's length, and the identifier of the applied obfuscation algorithm. This location information is aggregated and formatted to generate corresponding mask metadata. This mask metadata is maintained as an independent data structure, clearly recording which parts of the original payload were modified and how. This information is crucial for subsequent data processing or for authorized data users to understand the data state. Mask metadata is usually stored in a structured data format, such as JSON or binary encoding, for easy parsing and transmission.

[0071] In its implementation, the security evaluator begins by parsing transmission path features, which are a set of key attributes extracted from the header information of the raw data packets after deep parsing. The security evaluator first extracts the source IP address, destination IP address, sequence information of intermediate nodes traversed in the data packet's transmission path, and the timestamp information when the data packet was captured from the transmission path features. The sequence information of intermediate nodes may originate from the TTL field record of the IP packet or dedicated path tracing information. These extracted feature values ​​are converted into a standardized internal representation to facilitate subsequent query and analysis operations. The security evaluator uses the extracted source IP address, destination IP address, and sequence information of intermediate nodes as query conditions to access an independent historical path behavior database. The historical path behavior database is a continuously updated knowledge base that stores statistical records of the behavior of all observed transmission paths throughout history. For example, for a path from a specific source address to a destination address, the database may record information such as the average transmission delay, packet loss rate, temporal distribution characteristics of access frequency, and historical changes in the number of hops over a past period. The security evaluator submits query conditions through the database query interface, and the historical path behavior database returns a set of historical behavior records related to the currently queried path.

[0072] In its implementation, the security evaluator initiates a path analysis process after receiving historical behavior records. This analysis primarily involves assessing path stability and detecting abnormal access patterns. Path stability analysis is achieved by calculating the variance or moving average of indicators such as historical latency and packet loss rate; a path with less fluctuation is considered more stable. Abnormal access pattern detection employs rule-based or statistical model-based methods, such as checking whether the current access time deviates from the historical access patterns of the path, or whether any previously unseen abnormal nodes appear in the current path's node sequence. The analysis process closely integrates the timestamp information of the current data packet to determine whether the transmission behavior conforms to historical expectations in the time dimension. Internally, the security evaluator implements a weighted calculation model for quantifying and synthesizing the various analysis results. This model assigns preset weight coefficients to different analysis dimensions; for example, path stability score might account for 40% of the weight, abnormal access pattern index for 35%, and time compliance for 25%. The weighted calculation model multiplies the scores of each dimension by their respective weights and sums them, ultimately outputting a quantified path credibility score. Path reliability scores are typically normalized to a fixed range, such as integers from 0 to 100, with higher scores indicating higher reliability of the current transmission path. This score, as an objective measure of path security, is passed to the downstream data assembly stage.

[0073] Example 2: See Figure 3In practice, the data assembler receives obfuscated payload content and its associated mask metadata from the dynamic masking engine, and simultaneously receives path credibility scores from the security evaluator. The main function of the data assembler is to integrate and encapsulate these inputs into a structured, clearly labeled block of data to be transmitted. During initialization, the data assembler loads a predefined security level range mapping table, which divides continuous ranges of path credibility scores into discrete security level identifiers. For example, a specific mapping relationship can be defined as follows: a path credibility score in the range [0, 30] maps to the security level identifier "LOW"; a path credibility score in the range [31, 70] maps to the security level identifier "MEDIUM"; and a path credibility score in the range [71, 100] maps to the security level identifier "HIGH". The security level range mapping table typically exists in the form of a configuration file or a built-in data structure, allowing for adjustments based on the actual security policy.

[0074] In practice, the data assembler compares the received path trust score with the interval definitions in the security level interval mapping table to determine the security level identifier of the data block to be transmitted. The comparison process is implemented through a lookup or calculation logic; for example, the data assembler iterates through each interval in the security level interval mapping table, checking whether the path trust score falls within the lower and upper limits of a certain interval. Once a matching interval is found, the data assembler assigns the security level identifier corresponding to that interval to the currently processed data block. The security level identifier is a concise symbol used to quickly indicate the required protection level of the data block.

[0075] In practice, the data assembler encapsulates the obfuscated payload content, mask metadata, and a defined security level identifier. The encapsulation process follows a predefined data structure format that specifies the order, length, and encoding of the components. A typical data block encapsulation format may include a fixed-length header and a variable-length payload portion. The encapsulation header contains a privacy protection flag and a length field. The privacy protection flag is a flag indicating whether the payload content has been obfuscated by the dynamic masking engine; if the payload content has been obfuscated, the privacy protection flag is set to true (e.g., a binary value of 1), otherwise it is set to false (e.g., a binary value of 0). The length field indicates the total number of bytes in the subsequent payload portion. Following the encapsulation header is the encapsulated payload, which sequentially contains the obfuscated payload content itself, the mask metadata block, and the security level identifier field. The mask metadata block contains all the positional information and transformation parameters generated by the dynamic masking engine, while the security level identifier field stores the defined security level identifier as a string or an enumerated value.

[0076] In practical implementation, after the data assembler completes the encapsulation, it forms a complete data block to be transmitted. The data block to be transmitted is a continuous sequence of bytes, the structure of which can be explicitly parsed by downstream components. To ensure the flexibility and scalability of the data block structure, the encapsulation format can be designed to include version information. Version information allows the system to maintain backward compatibility when upgrading the data block structure in the future. When constructing the data block to be transmitted, the data assembler needs to ensure that all fields are encoded according to the agreed byte order to avoid parsing errors between different system platforms. In some embodiments, the mapping logic for the security level identifier can be designed to be more refined, not relying solely on a single path trust score. For example, the mapping logic can simultaneously consider the sensitivity level of the data itself, which may be determined by the business type of the data source. In this case, the determination of the security level identifier is a multi-factor decision-making process. The security level identifier S can be calculated using a weighted formula:

[0077] ;

[0078] in: This represents the path credibility score from the security evaluator. This represents the inherent sensitivity level of the data (e.g., represented by integers from 1 to 10). These are the weighting coefficients for path credibility scoring. It is a weight coefficient representing the inherent sensitivity level of the data, and satisfies... . This represents the floor function. The calculated S value is then mapped to a predefined security level range to determine the final security level identifier. This approach allows the security level identifier to more comprehensively reflect the overall security requirements of the data.

[0079] In some embodiments, the mask metadata can be compressed during encapsulation to reduce the overall size of the data block to be transmitted. Mask metadata typically contains a large amount of position offset and length information, which often exhibits repetitive patterns or can be used for differential encoding. Before placing the mask metadata into the encapsulation payload, the data assembler can invoke a lightweight compression algorithm (such as differential coding combined with Huffman coding) to process the mask metadata. Compressed mask metadata not only saves network bandwidth but also improves transmission efficiency. A flag or field can be added to the encapsulation header to indicate whether the mask metadata has been compressed, ensuring correct decompression by the receiver. It is understood that the data assembler is a key integration point in the entire data protection process, organically combining the privacy protection processing results with the network security assessment results. It is also understood that the standardized encapsulation format of the data block to be transmitted provides a unified interface for subsequent policy enforcement and data distribution.

[0080] Example 3: In a specific implementation, the data block to be transmitted is sent to the policy enforcement gateway, which is a key policy enforcement point in the network. Upon receiving the data block, the policy enforcement gateway initiates a parsing process, resolving the privacy protection flag and security level identifier encapsulated in the data block. The parsing operation follows the encapsulation format defined by the data assembler. The policy enforcement gateway reads the privacy protection flag field from the fixed-length header of the data block; this field is typically a single-bit flag. It also reads the security level identifier field from the encapsulated payload; this field may be a string or an enumerated integer value. The parsed privacy protection flag is a Boolean value indicating whether the payload content has been obfuscated, and the parsed security level identifier is a discrete symbol representing the security level of the data block.

[0081] In practical implementation, the policy enforcement gateway matches the corresponding transmission control policy and encryption policy from the policy library based on the parsing results. The policy enforcement gateway has a built-in policy library, which is a database storing various policy entries. This library defines the transmission control parameters and encryption algorithm types to be used under different combinations of privacy protection flags and security level identifiers. Transmission control parameters may include packet transmission priority, maximum allowed bandwidth, destination port number, or next-hop address. The encryption algorithm type specifies the encryption algorithm to be used, such as AES-256, RSA-2048, or the Chinese national standard SM4 algorithm. Each policy entry in the policy enforcement gateway's built-in policy library is associated with a unique condition combination, which consists of the values ​​of the privacy protection flag and the security level identifier.

[0082] In practice, the policy enforcement gateway uses the privacy protection flag and security level identifier of the data block to be transmitted as joint query conditions. The gateway searches its built-in policy library to retrieve transmission control policy entries and encryption policy entries that perfectly match the joint query conditions. This search process can be viewed as a key-value query, with the joint query conditions as the composite key and the policy entries as the values. The built-in policy library of the policy enforcement gateway typically employs an efficient index structure to accelerate the query process; for example, it creates hash indexes for different security level identifiers and then indexes different privacy protection flag states under each security level identifier. If the policy enforcement gateway finds a policy entry in its built-in policy library whose condition combination perfectly matches the privacy protection flag and security level identifier of the current data block to be transmitted, the gateway extracts the transmission control parameters and encryption algorithm type defined in that policy entry.

[0083] In practice, if no exact match is found, the policy enforcement gateway employs the default transmission control and encryption policies. The default policies are a predefined set of conservative security measures designed to handle unforeseen or unusual combinations of data block attributes. The default transmission control policy may include the lowest possible transmission priority and strict bandwidth limits, while the default encryption policy may specify the use of a strong encryption algorithm. Employing default policies ensures that the policy enforcement gateway can implement basic protection measures for data blocks under all circumstances, avoiding the risk of data leakage due to missing policies. The policy enforcement gateway logs policy matching failure events so that system administrators can subsequently analyze and update the gateway's built-in policy library.

[0084] In some embodiments, the policy matching logic can introduce priority and approximate matching mechanisms, rather than just exact matching. When multiple policy entries in the policy enforcement gateway's built-in policy library partially match the conditions of a join query, the policy enforcement gateway needs to select the optimal policy based on preset priority rules. Priority rules can be based on the granularity of the policy entries or their security level. For example, a priority weight factor can be assigned to each policy entry in the policy enforcement gateway's built-in policy library. Weighting factors The value ranges from 1 to 10, with higher values ​​indicating higher priority. The policy execution gateway first filters out all policy entries that partially match the current join query conditions (e.g., only security level identifiers match, or only privacy protection flags match), and then calculates the matching score between each filtered policy entry and the current join query conditions. Match score The calculation formula can be considered as follows:

[0085] ;

[0086] in: It is an indicator function that indicates whether the privacy protection tag matches (1 for a match, 0 for no match). It is an indicator function that indicates whether the security level identifier matches (1 for a match, 0 for no match). , , It is a coefficient that adjusts the importance of each part, and satisfies The policy enforcement gateway ultimately selects the option based on its matching score. The highest-ranking strategy entry is used as the matching result.

[0087] In some embodiments, the policy enforcement gateway's built-in policy library can support context-based dynamic policy adjustments. This library not only stores static policy entries but can also be associated with a context-aware engine. The context-aware engine monitors network status, system load, and threat intelligence in real time. When the context-aware engine detects a specific event (such as network congestion or security attack alerts), it dynamically adjusts the parameters of the relevant policy entries in the policy enforcement gateway's built-in policy library. For example, during a detected network attack, the context-aware engine might temporarily upgrade the encryption algorithm type of all policy entries involving the "MEDIUM" security level identifier to a higher level. This dynamic adjustment mechanism allows policy enforcement to adapt to constantly changing security environments. It can be understood that the policy enforcement gateway acts as the enforcer of security policies, translating abstract security labels into concrete network control and encryption actions. It can also be understood that the policy enforcement gateway's built-in policy library requires regular auditing and updates to reflect the latest security requirements and network topology changes.

[0088] Example 4: In specific implementation, the encryption engine extracts the encryption algorithm type and key index from the matched encryption policy entries. The encryption policy entries are provided by the policy enforcement gateway after successful matching. The encryption algorithm type is a specific identifier that specifies the encryption algorithm to be used, such as "AES-256-GCM" or "SM4-CBC". The key index is a unique reference to a specific encryption key in the key management service center. The encryption engine obtains the corresponding encryption key from the key management service center based on the key index. The key management service center is an independent system that provides secure key generation, storage, and distribution services. The encryption engine sends a key request message to the key management service center through an authenticated secure channel (e.g., a TLS-based API). The key request message contains the key index and the necessary authentication token. After verifying the legitimacy of the request, the key management service center returns the corresponding encryption key material. The encryption key material is usually transmitted in encrypted or obfuscated form to protect the security of the key itself.

[0089] In practice, the encryption engine uses the acquired encryption key and the specified encryption algorithm type to perform encryption operations on the entire data block to be transmitted. The encryption process strictly follows the specifications of the selected encryption algorithm. For example, if the encryption algorithm type is "AES-256-GCM", the encryption engine will initialize the AES-GCM encryptor, set the encryption key, generate a random number as the initialization vector, and then encrypt the plaintext content of the data block to be transmitted and calculate the authentication tag. The entire data block to be transmitted, including its encapsulation header and encapsulation payload, is considered as plaintext input for the encryption operation. The encryption operation outputs two parts: the ciphertext data itself and the authentication tag. The encryption engine generates the ciphertext data block and appends an encryption header information to identify the encryption algorithm and key version. The encryption header information is a structured data prefix, typically containing an encryption algorithm type identifier, key version number, initialization vector, and other parameters required by the algorithm. The encryption header information is appended in plaintext form before the ciphertext data block, enabling the receiver to identify the information required for decryption.

[0090] In practice, the encrypted data block is sent to the data distribution service, a component responsible for routing data to authorized recipients. The data distribution service maintains a list of authorized recipients and their respective data access permission configuration files. The authorized recipient list is a record of all terminal entities permitted to receive data from the system; each entry contains the recipient's unique identifier and network address information. The data access permission configuration file is a document associated with each authorized recipient, defining the range of data security levels, allowed data types, and other access control attributes authorized for that recipient. The data distribution service filters out authorized recipients with the corresponding access permissions based on the security level identifier in the encryption header information accompanying the encrypted data block. The data distribution service parses the encryption header information, extracting the security level identifier set by the data assembler in the previous stage and processed by the encryption engine along with the data block.

[0091] In practice, the data distribution service employs multiplexing to simultaneously transmit encrypted data blocks to all selected authorized recipients. Multiplexing means the service creates multiple copies of the encrypted data block and sends each copy in parallel to a selected authorized recipient via independent network connections or channels. This technology can be implemented using IP multicast, application-layer multicast, or simple multithreaded TCP / UDP connections. The data distribution service needs to manage the state of these distribution sessions, ensuring each authorized recipient successfully receives the data and retrying in case of transmission errors. When processing data blocks with high security levels, the service may enable enhanced transmission guarantee mechanisms, such as requiring recipients to return acknowledgments.

[0092] In some embodiments, the authorized recipient list and permission configuration maintained by the data distribution service can be dynamically updated. The authorized recipient list can be stored in a real-time queryable database, rather than in a static configuration file. When the data distribution service needs to filter recipients, it sends a query request to the authorization management server, which includes a security level identifier extracted from the encrypted data block. The authorization management server returns a list of recipients currently authorized to access data at that security level, based on the latest permission policy. This mechanism allows permission changes to take effect immediately without requiring a restart of the data distribution service. The list returned by the authorization management server can include a time-to-live (TTL) value, which the data distribution service can cache until the TTL expires.

[0093] In some embodiments, the filtering logic of the data distribution service can incorporate optimizations based on load balancing or network topology. When the number of authorized recipients selected is large, direct multi-path distribution may put pressure on the data distribution service or network bandwidth. The data distribution service can calculate a distribution priority score. This determines the order of distribution or resource allocation. Distribution priority score. The calculation can take into account the receiver's historical reliability. Delay of the current network path and the security level identifier of the data block The numerical mapping. To ensure dimensional consistency and obtain a dimensionless distribution priority score, a possible calculation formula is as follows:

[0094] ;

[0095] in: It is a normalized constant with the dimension of time. It is a small positive number to prevent the logarithm from being negative. This represents the logarithmic function with base 10. See Table 1.

[0096] Table 1: Encryption Header Information Structure

[0097]

[0098] Example 5: In a specific implementation, the data distribution service parses the encrypted header information of the encrypted data block, extracting the security level identifier. The encrypted header information is located at the beginning of the encrypted data block and has a fixed or inferable structural format. The data distribution service reads and interprets the content field by field according to the predefined encrypted header information format specification. The encrypted header information contains a field specifically for storing the security level identifier, which may exist in string form or as an enumerated integer value (such as 3, 2, 1). The parsing logic of the data distribution service can recognize this encoding method and convert the read raw value into a standardized security level identifier representation used internally. The parsing process needs to handle details such as byte order, fixed-length or variable-length fields to ensure accurate extraction of the complete security level identifier information.

[0099] In practice, the data distribution service reads the authorized recipient list, which is a list of all potential data receiving endpoints, typically stored in a database table or a structured configuration file. The data distribution service queries the data access permission configuration file for each authorized recipient. This configuration file is an independent file associated with each entry in the authorized recipient list, defining the range of data security levels, the types of data that can be accessed, and other constraints for that recipient. The data access permission configuration file explicitly specifies the "allowed security level range." For example, a configuration might specify a allowed security level range of ["LOW", "MEDIUM"], meaning that this recipient can only receive data blocks with a security level of "LOW" or "MEDIUM," but not data at the "HIGH" level. The data distribution service obtains the currently active data access permission configuration file for each authorized recipient by accessing the configuration storage system or calling the permission management API.

[0100] In practice, the data distribution service compares the extracted security level identifier with the range of allowed security levels in each authorized recipient's data access permission configuration file. The comparison is based on a predefined security level order, such as a total order: "LOW" < "MEDIUM" < "HIGH". The data distribution service checks whether the security level identifier extracted from the encrypted data block falls within the range defined in the authorized recipient's data access permission configuration file. For example, if the extracted security level identifier is "MEDIUM", and the allowed security level range for an authorized recipient is ["LOW", "HIGH"], then "MEDIUM" falls within this range, and the recipient is initially determined to have the necessary permissions. The data distribution service performs this comparison operation for each authorized recipient in the list.

[0101] In practice, the data distribution service only retains authorized recipients whose security level identifiers fall within the allowed access security level range as valid recipients. After the comparison operation is complete, the data distribution service generates a subset of valid recipients, which contains the identifiers of all authorized recipients who passed the permission check. Authorized recipients whose allowed access security level range defined in their data access permission configuration file does not include the security level identifier of the current encrypted data block will be excluded from this distribution task. For example, a recipient only authorized to access "LOW" level data will not be included as a valid recipient when faced with an encrypted data block with a security level identifier of "HIGH". This filtering mechanism ensures that data can only be distributed to entities with the corresponding permissions, following the principle of least privilege.

[0102] In practice, after the data distribution service completes the transmission of the encrypted data block, the receiving end decryption module begins operation on the authorized receiving side. The receiving end decryption module selects an appropriate decryption key and algorithm based on the encryption header information of the encrypted data block. First, the receiving end decryption module parses the encryption header information at the front of the encrypted data block to obtain the encryption algorithm type identifier and key version number. Internally, the receiving end decryption module maintains a local keystore or has access to a key distribution service. It uses the key version number as an index to query and retrieve the corresponding decryption key. Simultaneously, the receiving end decryption module loads the corresponding decryption algorithm implementation based on the encryption algorithm type identifier. Selecting an appropriate decryption key and decryption algorithm is a prerequisite for correctly recovering the data.

[0103] In practice, the receiving end decryption module decrypts the ciphertext data block to recover the data block to be transmitted. The decryption operation uses parameters obtained from the encryption header and the newly selected decryption key to perform cryptographic decryption operations on the main body of the ciphertext data block following the encryption header. The decryption process strictly follows the specifications of the selected algorithm; for example, in AES-GCM mode, the decryption operation simultaneously verifies the attached authentication tag to ensure data integrity and authenticity. If the decryption verification is successful, the output of the receiving end decryption module is the original, structurally complete plaintext data block to be transmitted. If decryption fails, the receiving end decryption module discards the data and records a security event. In practice, the receiving end parsing module parses the recovered data block to be transmitted, reading its privacy protection flag and security level identifier. The receiving end parsing module understands the encapsulation format of the data block to be transmitted. It parses the encapsulation header of the data block to be transmitted to read the privacy protection flag, which is usually a Boolean flag. Then, the receiving end parsing module continues to parse the encapsulation payload of the data block to be transmitted, locating and extracting the security level identifier field. The receiving end parsing module passes the parsed privacy protection tags and security level identifiers to the subsequent processing logic. These identifiers determine how the data will be further processed on the receiving end.

[0104] In practice, the decision to invoke the data restoration module to reverse-engineer the obfuscated data in the payload is based on the privacy protection flag. If the privacy protection flag is "false" or not set, it means the payload content is not obfuscated, and the data restoration step is skipped, with the payload content sent to the application layer. If the privacy protection flag is "true" or set, it means the sensitive parts of the payload content have been obfuscated, and the receiving end parsing module invokes the data restoration module. The data restoration module uses the mask metadata carried in the data block to be transmitted. This mask metadata precisely indicates the location of the specific obfuscated data segment in the payload and the type of obfuscation algorithm used. The data restoration module uses a built-in restoration algorithm corresponding to the sender's dynamic masking engine, or replaces the obfuscated data with placeholders or locally generated authorized data based on the metadata information, to reverse-engineer the obfuscated data in the payload. The goal of data restoration is to generate clear data that the application layer can understand and process, or alternative data that meets privacy protection requirements.

[0105] Finally, the processed data is sent to the business application layer of the distribution automation system for further processing. After decryption and possible restoration operations, the data has been transformed into a format usable by the business application layer. This data is then passed to upper-layer applications of the distribution automation system, such as SCADA systems for real-time monitoring, DMS for distribution management, or data analysis platforms for trend prediction. The business application layer processes this data like ordinary data, without needing to worry about the underlying complex data security and privacy protection processes; the entire protection mechanism is transparent to the business applications.

[0106] It is understandable that the processing flow on the authorized receiver side is the reverse of the sender's protection flow. The authorized receiver side's processing flow aims to securely restore data utility while respecting privacy constraints. Optionally, after reading the security level identifier, the receiving end's parsing module can compare it with the expected security level of the current session; if they do not match, an alarm can be triggered. Optionally, after receiving data, the business application layer can send an acknowledgment signal to the data distribution service or the sender to confirm that the data has been successfully received and processed. Optionally, key steps in the entire receiving and processing process, such as successful / failed decryption and the execution status of the restoration operation, can be recorded in the local security audit log.

[0107] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0108] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A method for data security and privacy protection in a power distribution automation system, characterized in that, The implementation process includes: Deploy data sensing probes at the data acquisition end of the power distribution automation system to capture raw data packets flowing through network nodes in real time; Deeply analyze the captured raw data packets to extract the payload content and transmission path characteristics of the data packets; The payload content is input into the dynamic masking engine, which performs real-time obfuscation on specific data segments according to predefined privacy field rules. At the same time, the transmission path characteristics are fed into the security evaluator to calculate the path credibility score; Based on the output of the dynamic masking engine and the path credibility score of the security evaluator, a data block to be transmitted is generated with privacy protection tags and security level identifiers; The specific steps for feeding the transmission path features into the security evaluator and calculating the path credibility score include: The security evaluator extracts the source address, destination address, sequence of intermediate nodes, and timestamp information from the transmission path characteristics. Query the historical path behavior database to obtain historical behavior records of the source address, destination address, and intermediate node sequence; Based on historical behavior records, analyze the stability of the path and abnormal access patterns, and combine timestamp information to determine whether the current transmission behavior meets expectations; By combining the results of various analyses using a weighted calculation model, a quantitative path credibility score is output.

2. The data security and privacy protection method for a power distribution automation system according to claim 1, characterized in that, The process of inputting the payload content into the dynamic masking engine and performing real-time obfuscation on specific data segments according to predefined privacy field rules includes the following steps: A privacy field rule base is established, which defines the sensitive data types that need to be protected in the power distribution automation system and their corresponding data format characteristics; The dynamic masking engine scans the payload content byte by byte and performs pattern matching with format features in the privacy field rule base; When a specific data segment that conforms to the characteristics of a sensitive data format is identified, the built-in obfuscation algorithm is triggered to perform an irreversible transformation on the specific data segment. Record the location information of each obfuscated specific data segment in the original payload and generate the corresponding mask metadata.

3. The data security and privacy protection method for a power distribution automation system according to claim 1, characterized in that, The specific steps for generating the data block to be transmitted with privacy protection markers and security level identifiers include: The data assembler receives the obfuscated payload content and its mask metadata from the dynamic masking engine; The data assembler also receives path credibility scores from the security evaluator; The data assembler maps path credibility scores to predefined security level ranges to determine the security level identifier of the data block to be transmitted; The obfuscated payload content, mask metadata, and security level identifier are encapsulated, and a privacy protection flag is set in the encapsulation header to form a complete data block to be transmitted.

4. The data security and privacy protection method for a power distribution automation system according to claim 3, characterized in that, After forming the data block to be transmitted, the following steps are further included: Send the data block to be transmitted to the policy enforcement gateway; The policy enforcement gateway parses the privacy protection tags and security level identifiers encapsulated in the data blocks to be transmitted; Based on the parsing results, the policy enforcement gateway matches the corresponding transmission control policy and encryption policy from the policy library; The matched encryption strategy is used to encrypt the data block to be transmitted, forming a ciphertext data block.

5. A data security and privacy protection method for a power distribution automation system according to claim 4, characterized in that, The policy execution gateway matches the corresponding transmission control policy and encryption policy from the policy library based on the parsing result. The specific steps include: The policy execution gateway has a built-in policy library, which defines the transmission control parameters and encryption algorithm types to be used under different combinations of privacy protection flags and different security level identifiers; The policy enforcement gateway uses the privacy protection tag and security level identifier of the data block to be transmitted as joint query conditions; Search the policy library to obtain the transmission control policy entries and encryption policy entries that completely match the joint query conditions; If no exact match is found, the default transmission control and encryption policies will be used.

6. A data security and privacy protection method for a power distribution automation system according to claim 5, characterized in that, The specific steps of encrypting the data block to be transmitted using the matched encryption strategy include: The encryption engine extracts the encryption algorithm type and key index from the matched encryption policy entries; Obtain the corresponding encryption key from the key management service center based on the key index; Use the acquired encryption key and the specified encryption algorithm type to perform encryption operations on the entire block of data to be transmitted; Generate ciphertext data blocks and attach encryption header information to identify the encryption algorithm and key version.

7. A data security and privacy protection method for a power distribution automation system according to claim 6, characterized in that, After generating the ciphertext data block, the following steps are further included: Send the encrypted data block to the data distribution service; The data distribution service maintains a list of authorized recipients and their respective data access permission configuration files; The data distribution service filters out authorized recipients with corresponding access permissions based on the security level identifier in the encrypted header information attached to the encrypted data block; Multiplexing technology is used to transmit encrypted data blocks simultaneously to all selected authorized recipients.

8. A data security and privacy protection method for a power distribution automation system according to claim 7, characterized in that, The data distribution service filters out authorized recipients with corresponding access permissions based on the security level identifier in the encryption header information attached to the encrypted data block. The specific steps include: The data distribution service parses the encryption header information of the encrypted data block and extracts the security level identifier from it; Read the list of authorized recipients and query the data access permission configuration file for each authorized recipient one by one; The extracted security level identifier is compared with the range of security levels allowed in the data access permission configuration file of each authorized recipient; Only authorized recipients whose security level identifiers fall within the permitted security level range are retained as valid recipients.

9. A data security and privacy protection method for a power distribution automation system according to claim 8, characterized in that, After the data distribution service completes the transmission of the encrypted data block, the following steps are further included: On the authorized receiver side, the receiving decryption module selects the appropriate decryption key and decryption algorithm based on the encryption header information of the ciphertext data block; The receiving end decryption module decrypts the ciphertext data block to recover the data block to be transmitted; The receiving end parsing module parses the recovered data block to be transmitted and reads its privacy protection mark and security level identifier; Based on the privacy protection flag, it is determined whether to invoke the data restoration module to perform a reverse restoration operation on the obfuscated data in the payload; Finally, the processed data is sent to the business application layer of the power distribution automation system for further processing.

Images