Secure transmission method and system for power business data facing sensitive data

Abstract

This invention discloses a secure transmission method and system for sensitive power business data, belonging to the blockchain field. The method includes: when a data packet needs to be transmitted from a first security domain to a second security domain, obtaining a content digest, sensitivity level, and identity information; determining a first permission level based on the identity information, and matching the second security domain security level, the first permission level, and the sensitivity level in a rule base to obtain a second permission level, a rule identifier, and a version number; combining the second permission level, the second security domain identifier, the rule identifier, and the version number according to encoding rules to generate a permission tag, calculating the combined hash value of the content digest and the permission tag, and writing it along with the current timestamp into the blockchain to obtain a certificate of authenticity; re-encapsulating the permission tag, the certificate of authenticity, and the data packet into a data entity and sending it to the second security domain for the recipient to verify the certificate of authenticity and access it according to the second permission level. Therefore, this invention can improve the security of data transmission across security domains.

Description

Technical Field

[0001] This invention relates to the field of blockchain, and more particularly to a method and system for secure transmission of sensitive power business data. Background Technology

[0002] In electricity marketing, sensitive data such as customer information, electricity consumption data, and transaction records are typically stored in the high-security domain of the internal network. To support field operations, mobile inspections, and mobile marketing, this data needs to be transferred across domains from the high-security domain of the internal network to the low-security domain of the external network, enabling mobile terminals to remotely access core business data. Cross-domain transmission has become a crucial link in ensuring the continuity and efficiency of electricity marketing operations.

[0003] In existing technologies, cross-security domain data transmission mainly employs two methods: one is a direct blocking strategy, prohibiting the cross-domain distribution of sensitive data, but this severely restricts mobile office and on-site operations; the other allows cross-domain transmission, but existing access permissions cannot be effectively continued or constrained in the target domain, lacking a dynamic permission downgrade mechanism for cross-domain scenarios. When data moves from a high-security domain to a low-security domain, the lack of automatic contraction and adaptation of operational permissions easily leads to security risks such as uncontrolled permissions, unauthorized access, data leakage, or tampering. Furthermore, existing solutions generally lack traceable records of permission downgrade decision-making processes and cross-domain transfer behaviors, failing to meet the power industry's requirements for data security auditing and compliance supervision. Summary of the Invention

[0004] This invention provides a method and system for secure transmission of power business data for sensitive data, which can improve the security of power business data transmission across security domains.

[0005] The first aspect of this invention provides a method for secure transmission of power service data oriented towards sensitive data, comprising: When a data packet needs to be transmitted from the first security domain to the second security domain, the content summary, sensitivity level, and identity information of the accessing subject of the data packet are obtained. Based on the identity information, the first permission level of the access subject in the first security domain is determined. Based on the security level of the second security domain, the first permission level, and the sensitivity level, a match is made in a preset rule base to determine the second permission level applicable to the second security domain, the rule identifier and version number of the downgrade rule. The second permission level, the identifier of the second security domain, the rule identifier, and the version number are combined according to a preset encoding rule to generate a permission tag. A cryptographic hash function is used to calculate the combined hash value of the combined data consisting of the content digest and the permission tag. The combined hash value is packaged with the current timestamp and written into the blockchain to receive the evidence returned by the blockchain. The permission tag, the evidence storage certificate, and the transmission data packet are repackaged into a new data entity, and the data entity is sent to the second security domain. After the second security domain verifies the evidence storage certificate in the received data entity, it allows access to the data entity according to the second permission level.

[0006] This invention, through parsing transmitted data packets, can pre-identify key data attributes and visitor identities, laying the foundation for subsequent refined access control and avoiding security blind spots caused by blind transmission. By determining the first and second permission levels, it achieves dynamic and automatic permission degradation during cross-domain processes, ensuring that when data enters a lower security domain, operational permissions are forcibly narrowed to the range matching the security requirements of that domain, fundamentally preventing the unauthorized inheritance or abuse of high permissions. By generating permission tags, the downgraded permission information forms an inseparable structured binding with the target security domain and the adopted rules, facilitating rapid identification of the source and legitimacy of permissions during subsequent verification. By calculating combined hash values, it can cryptographically link data content and permission tags. The system establishes a strong connection between data and permissions to prevent individual tampering or stripping of content or permissions. Leveraging the immutability and timestamping properties of blockchain, it permanently stores the association between data content and permission tags, as well as the moment of degradation, providing authoritative verification for subsequent access and effectively resisting post-hoc repudiation or log forgery attacks. By encapsulating and transmitting data, permission constraints and evidence flow along with the data, avoiding the control failures caused by the separation of permissions and data in traditional solutions. Verification enables access control and permission enforcement based on blockchain credentials within the target security domain, ensuring that only data entities that pass integrity verification and have valid permission tags can be accessed with downgraded permissions, thus improving the overall security of power business data transmission across security domains in a closed loop.

[0007] Further, the step of calculating the combined hash value of the combined data consisting of the content digest and the permission tag using a cryptographic hash function, packaging the combined hash value with the current timestamp, and writing it into the blockchain to receive the evidence returned by the blockchain includes: The content summary and the permission tag are concatenated into combined data in a preset order, and the combined data is hashed by calling the cryptographic hash function to obtain the combined hash value. The combined hash value and the current timestamp are assembled into a notarized transaction, wherein the notarized transaction includes at least the combined hash value, the current timestamp, and the signature of the transaction initiator; The notarized transaction is broadcast to multiple consensus nodes in the blockchain network, and each consensus node performs consensus verification on the notarized transaction. After consensus verification is passed, the notarized transaction is written into the distributed ledger of the blockchain, and the transaction hash returned by the blockchain system is received as the notarized certificate.

[0008] By binding the permission downgrade result with the content summary and storing it on the blockchain, the immutability and traceability of the permission tag and content summary are ensured, providing a reliable basis for subsequent verification by the recipient.

[0009] Furthermore, obtaining the content digest, sensitivity level, and identity information of the accessing subject of the transmitted data packet includes: A preset hash function is invoked to calculate the data payload in the transmitted data packet, thereby generating the content digest; Extract the identity information of the accessing subject from the metadata header of the transmitted data packet; The initial sensitivity level tag is read from the metadata header to obtain the first sensitivity level. The content summary is used as an index to query the preset sensitive data feature library. If a match is found, the second sensitivity level is obtained. The first sensitivity level and the second sensitivity level are comprehensively evaluated according to the preset security policy to determine the sensitivity level.

[0010] Further, determining the first permission level of the access subject in the first security domain based on the identity information includes: The subject identifier in the identity information is queried through a preset role mapping table to determine the role category of the accessing subject in the system; Using the role category as the key, query the permission mapping table of the first security domain to obtain the original permission set; The original permission set is filtered according to preset dynamic permission constraint rules, and the filtered permission set is determined as the first permission level.

[0011] Further, the step of matching the second security domain's security level, the first permission level, and the sensitivity level in a preset rule base to determine the rule identifier and version number applicable to the second permission level and the downgrade rule for the second security domain includes: Combine the first permission level, the sensitivity level, and the security level of the second security domain into a permission downgrade query key; Using the permission downgrade query key as an index, a matching operation is performed in a preset rule base, wherein the rule base contains multiple rule entries; If a unique first rule entry is matched, the downgraded permission level in the first rule entry is determined as the second permission level, and the rule identifier and the version number of the first rule entry are extracted. If multiple second rule entries are matched, the third rule entry with the highest priority is determined according to the preset priority field in each second rule entry, and the corresponding downgraded permission level in the third rule entry is extracted and determined as the second permission level, the rule identifier and the version number.

[0012] This enables dynamic and automatic degradation of permissions during cross-domain processes, ensuring that when data enters a low-security domain, operation permissions are forcibly reduced to the range that matches the security requirements of that domain, fundamentally preventing high permissions from being illegally inherited or abused.

[0013] Further, the step of combining the second permission level, the identifier of the second security domain, the rule identifier, and the version number according to a preset encoding rule to generate a permission tag includes: The second permission level, the identifier of the second security domain, the rule identifier, and the version number are converted into string form respectively to obtain the first standardized string, the second standardized string, the third standardized string, and the fourth standardized string; The first, second, third, and fourth standardized strings are concatenated in sequence according to the preset delimiter to generate a combined string; The combined string is encoded to obtain the permission tag.

[0014] By generating permission tags, the downgraded permission information is structurally bound to the target security domain and the rules adopted, making it easier to quickly identify the source and legitimacy of permissions during subsequent verification.

[0015] Furthermore, the step of re-encapsulating the permission tag, the evidence storage certificate, and the transmission data packet into a new data entity includes: Convert the permission tags into a permission tag byte array and obtain the permission tag length of the permission tag byte array; Convert the evidence storage certificate into an evidence storage certificate byte array, and obtain the evidence storage certificate length of the evidence storage certificate byte array; According to the preset encapsulation header format, the encapsulation protocol identifier, the version number of the downgrade rule, the length of the permission tag, and the length of the evidence storage certificate are combined into an encapsulation header byte array; The data entity is generated by sequentially concatenating the encapsulated header byte array, the permission tag byte array, the evidence storage byte array, and the transmission data packet.

[0016] By encapsulating and transmitting data in this way, permission constraints and evidence information flow along with the data, avoiding the control failure caused by the separation of permissions and data in traditional solutions.

[0017] Further, the step of enabling the second security domain to access the data entity according to the second permission level after verifying the evidence in the received data entity includes: After receiving the data entity, the second security domain parses the received data packet, the permission tag, and the evidence storage certificate from the data entity according to the same preset encapsulation header format as during encapsulation. The identifiers of the second permission level and the second security domain are parsed from the permission tags; The content digest of the parsed received data packet is recalculated to obtain the target content digest. The target content digest is combined with the parsed permission tag to obtain the combined result. The combined result is then recalculated using the same cryptographic hash function to obtain the target combined hash value. Using the evidence certificate as the query key, retrieve the pre-stored combined hash value and the block timestamp of the block where the evidence certificate is located from the blockchain, and compare the target combined hash value with the pre-stored combined hash value. If the comparison matches and the difference between the block timestamp and the current time is within a preset validity period, the verification is successful, and the second security domain grants access to the data payload in the received data packet according to the second permission level.

[0018] This verification process enables access control and permission enforcement based on blockchain credentials within the target security domain. It ensures that only data entities that pass integrity verification and have valid permission tags can be accessed with downgraded permissions, thereby improving the overall security of power business data transmission across security domains in a closed loop.

[0019] Another embodiment of the present invention provides a secure transmission system for power business data oriented towards sensitive data, comprising: The first module is used to obtain the content summary, sensitivity level, and identity information of the accessing subject of the data packet when the data packet needs to be transmitted from the first security domain to the second security domain. The second module is used to determine the first permission level of the access subject in the first security domain based on the identity information, and to match the second permission level, the first permission level and the sensitivity level in a preset rule base to determine the rule identifier and version number of the second permission level and the downgrade rule applicable to the second security domain. The third module is used to combine the second permission level, the identifier of the second security domain, the rule identifier, and the version number according to a preset encoding rule to generate a permission tag, and to use a cryptographic hash function to calculate the combined hash value of the combined data composed of the content digest and the permission tag. The combined hash value is then packaged with the current timestamp and written into the blockchain to receive the evidence returned by the blockchain. The fourth module is used to repackage the permission tag, the evidence storage certificate, and the transmission data packet into a new data entity, and send the data entity to the second security domain, so that after the second security domain verifies the evidence storage certificate in the received data entity, it allows access to the data entity according to the second permission level.

[0020] Furthermore, the third module includes: The first unit is used to concatenate the content summary and the permission tag into combined data in a preset order, and call the cryptographic hash function to perform a hash operation on the combined data to obtain a combined hash value. The second unit is used to assemble the combined hash value and the current timestamp into a notarized transaction, wherein the notarized transaction includes at least the combined hash value, the current timestamp, and the signature of the transaction initiator; The third unit is used to broadcast the evidence storage transaction to multiple consensus nodes of the blockchain network, and each consensus node performs consensus verification on the evidence storage transaction. The fourth unit is used to write the notarized transaction into the distributed ledger of the blockchain after the consensus verification is passed, and to receive the transaction hash returned by the blockchain system as notarized proof. Attached Figure Description

[0021] To more clearly illustrate the technical solution of this application, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0022] Figure 1 This is a flowchart illustrating an embodiment of the secure transmission method for sensitive power business data provided in this application; Figure 2 This is a flowchart illustrating one embodiment of steps S201 to S204 provided in this application; Figure 3 This is a flowchart illustrating one embodiment of steps S301 to S305 provided in this application; Figure 4This is a schematic diagram of an embodiment of the secure transmission system for sensitive power business data provided in this application. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below with reference to the accompanying drawings of the embodiments. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0024] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains; the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the application; the terms “comprising” and “having”, and any variations thereof, in the specification, claims, and foregoing description of the drawings are intended to cover non-exclusive inclusion.

[0025] In the description of the embodiments of this application, technical terms such as "first" and "second" are used only to distinguish different objects and should not be construed as indicating or implying relative importance or implicitly specifying the number, specific order, or primary and secondary relationship of the indicated technical features. In the description of the embodiments of this application, "multiple" means two or more, unless otherwise explicitly defined.

[0026] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0027] In the description of the embodiments in this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship.

[0028] In the description of the embodiments of this application, the term "multiple" refers to two or more (including two), similarly, "multiple sets" refers to two or more (including two sets), and "multiple pieces" refers to two or more (including two pieces).

[0029] In the description of the embodiments of this application, unless otherwise expressly specified and limited, technical terms such as "installation," "connection," "joining," and "fixing" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral part; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; they can refer to the internal communication of two components or the interaction between two components. For those skilled in the art, the specific meaning of the above terms in the embodiments of this application can be understood according to the specific circumstances.

[0030] See Figure 1 To improve the security of power business data transmission across security domains, an embodiment of the present invention provides a secure transmission method for power business data oriented towards sensitive data, including steps S101 to S104: Step S101: When a data packet needs to be transmitted from the first security domain to the second security domain, obtain the content summary, sensitivity level, and identity information of the accessing subject of the data packet. In some embodiments, step S101 includes: calling a preset hash function to calculate the data payload in the transmitted data packet to generate the content digest; extracting the identity information of the accessing subject from the metadata header of the transmitted data packet; reading an initial sensitivity level tag from the metadata header to obtain a first sensitivity level; using the content digest as an index to query a preset sensitive data feature library; if a match is found, obtaining a second sensitivity level; and comprehensively evaluating the first sensitivity level and the second sensitivity level according to a preset security policy to determine the sensitivity level. Specifically, when a transmitted data packet needs to be sent from a first security domain to a second security domain, the system first calls a preset hash function (e.g., national cryptographic standard SM3 or SHA-256) to perform hash calculation on the data payload in the transmitted data packet (i.e., the actual business data after removing headers, trailers, and other control information) to generate a fixed-length content digest. Then, the identity information of the accessing subject is extracted from the metadata header of the transmitted data packet. Simultaneously, a pre-defined initial sensitivity level tag is read from the same metadata header and recorded as the first sensitivity level. Next, the content digest just calculated is used as an index to query a pre-built sensitive data feature library. If a record in the feature database is matched based on the content digest, the pre-defined second sensitivity level for that record is obtained; otherwise, the second sensitivity level is considered empty or the same as the first sensitivity level. After obtaining the first and second sensitivity levels, if they differ, the higher one is taken as the final sensitivity level; if one is missing, the other is used; if both are missing, the lowest sensitivity level is used by default. This determines the actual sensitivity level used for the data packet.

[0031] It should be noted that a security domain refers to a logically or physically isolated area within a power business system, defined according to security level, business type, or network boundary. The first security domain can be understood as the area where the data sender is located (such as a high-security production area), and the second security domain is the area where the data receiver is located (such as a low-security management area).

[0032] It should be noted that the so-called access subject refers to the user, program or device entity that initiates this data transmission operation. The identity information usually includes subject identifiers (such as user ID, role ID or device certificate serial number).

[0033] It should be noted that the sensitive data feature database is built using an offline construction and online update strategy. Specifically: First, historical data samples are collected from the power business system, including but not limited to: customer profile information, electricity consumption details, payment records, equipment operating parameters, work order instructions, etc. Each sample undergoes data cleaning to remove null values ​​and obviously abnormal records, and structured fields (such as voltage level and electricity category) and unstructured text (such as remarks and operation descriptions) are uniformly converted to a standard format. Second, each sample is labeled with a sensitivity level. The labeling method combines "expert rules + semi-supervised clustering": the expert team divides the samples into four levels—"extremely high sensitivity," "high sensitivity," "moderate sensitivity," and "low sensitivity"—based on the power industry data security classification standards (such as the "Power Data Classification and Grading Guide"), forming an initial labeling seed set; for the remaining unlabeled samples, TF-IDF is used to extract text features, and K-means clustering algorithm is used to classify them into similar seed categories. Experts then review and correct samples with ambiguous cluster boundaries to ensure labeling accuracy. Third, key features of each sample category are extracted for subsequent real-time matching. Specifically, this includes: ① key field combinations, such as the co-occurrence of "household number + ID card number"; ② regular expression patterns, such as regular expressions for mobile phone numbers and bank account numbers; ③ statistical features, such as the information entropy and character distribution patterns of a certain field. These features are associated with the corresponding sensitivity levels to form rule entries. At the same time, the hash value of the data payload of each sample is calculated (using the SM3 algorithm), and a mapping index of "hash value → sensitivity level" is established. This index supports O(1) lookup and is used to quickly find known sensitive data with content digests during transmission. Finally, the above rule entries and hash mapping table are uniformly stored in a distributed configuration center or a local embedded database (such as SQLite), and a version number and incremental update mechanism are designed. When new sensitive data samples are generated, incremental patches are generated through the same annotation and feature extraction process and periodically distributed to the transmission agent nodes of each security domain, thereby realizing the dynamic evolution of the feature library.

[0034] Using the above methods, the system can accurately obtain the content summary, identity information, and sensitivity level of the data packet after comprehensive evaluation, providing a reliable basis for subsequent permission downgrade.

[0035] Step S102: Determine the first permission level of the access subject in the first security domain based on the identity information; match the second permission level, the first permission level and the sensitivity level in the preset rule base according to the security level of the second security domain, the first permission level and the sensitivity level to determine the second permission level applicable to the second security domain, the rule identifier and version number of the downgrade rule; In some embodiments, determining the first permission level of the access subject in the first security domain based on the identity information includes: querying a preset role mapping table using the subject identifier in the identity information to determine the role category of the access subject in the system; querying the permission mapping table local to the first security domain using the role category as the key to obtain the original permission set; and filtering the original permission set according to preset dynamic permission constraint rules to determine the filtered permission set as the first permission level. Specifically, firstly, based on the subject identifier in the identity information (such as user ID "zhang_san" or device serial number "GW_2024001"), a pre-configured role mapping table local to the first security domain is queried to determine the role category of the access subject. Using the role category as the key, the permission mapping table local to the first security domain is queried, where each row in the permission mapping table records the original permission set that a role category has by default in the security domain, thereby matching and obtaining the original permission set that the role should have under ideal conditions (i.e., without any temporary restrictions or environmental constraints). However, in actual power business environments, the actual available permissions of the same role often change dynamically at different times, under different loads, or under different security situations. For example, when a system is deemed to be in a "high-risk operating state," even an operations engineer might be temporarily prohibited from executing control commands. Or, during automatic maintenance periods at night, certain write operations might be restricted. Therefore, the original set of permissions obtained earlier needs to be input into the dynamic permission constraint rule matching engine, one by one. For any rule that meets the triggering conditions in the dynamic permission constraint rule, the corresponding constraint action is applied. For instance, if the original permission set includes "execute control commands," but the current time is 2 AM and a dynamic rule stipulates "prohibit all write operations from 12 AM to 6 AM," then the "execute control commands" permission is filtered out. After filtering, the remaining permission set is the first level of permission that the access subject can actually use at the current time and in the current environment.

[0036] It's important to note that the role mapping table functions similarly to an "identity-role" lookup book, recording the system role category corresponding to each entity identifier. For example, "zhang_san" corresponds to "Operations Engineer," and "GW_2024001" corresponds to "Data Acquisition Terminal." Role categories are typically coarse-grained, such as "System Administrator," "Business Operator," "Read-Only Auditor," and "Terminal Device."

[0037] It should be noted that the original permission set is usually stored in the form of a permission bitmap or permission list, such as "Read real-time data", "Write to historical database", "Execute control command", "Export report", etc.

[0038] It should be noted that the preset dynamic permission constraint rules are stored in an independent rule base in the first security domain. Each rule includes triggering conditions and constraint actions. Triggering conditions can be a time range (e.g., "23:00 to 05:00 the next day"), system load (e.g., "CPU utilization exceeds 85%)", security alarm level (e.g., "Level 3 or above alarms have occurred"), or even a sensitivity level determined in the previous step (e.g., "The currently transmitted data packet has a highly sensitive sensitivity level"). Constraint actions include "deleting a permission", "adding a permission", and "changing a permission to read-only", etc.

[0039] In some embodiments, the step of matching in a preset rule base based on the security level of the second security domain, the first permission level, and the sensitivity level to determine the second permission level, the rule identifier, and the version number of the downgrade rule applicable to the second security domain includes: combining the first permission level, the sensitivity level, and the security level of the second security domain into a permission downgrade query key; using the permission downgrade query key as an index to match in the preset rule base, wherein the rule base contains multiple rule entries; if a unique first rule entry is matched, the downgraded permission level in the first rule entry is determined as the second permission level, and the rule identifier and the version number of the first rule entry are extracted; if multiple second rule entries are matched, the third rule entry with the highest priority is determined according to the preset priority field in each second rule entry, and the corresponding downgraded permission level in the third rule entry is extracted and determined as the second permission level, the rule identifier, and the version number. Specifically, after determining the first permission level of the accessing subject in the first security domain and the final sensitivity level of the data packet, the system also needs to know the security level of the second security domain itself. Subsequently, to implement permission downgrading during cross-domain transmission, the system directly concatenates the first permission level, sensitivity level, and security level of the second security domain into a single string or structured key-value pair, called the "permission downgrading query key." After obtaining the permission downgrading query key, the system iterates through the entries in the rule base. If only one rule entry matches the query key, that rule is the unique first rule entry. The system directly determines the "downgraded permission level" specified in that rule entry as the actual usable second permission level in the second security domain, and simultaneously extracts the rule identifier and version number of that entry. If multiple rule entries in the rule base match the current query key, all matched rule entries (called second rule entries) are sorted from highest to lowest priority, and the one with the highest priority (called the third rule entry) is selected. Then, the downgraded permission level, rule identifier, and version number are extracted from this entry, serving as the final second permission level, rule identifier, and version number, respectively.

[0040] It should be noted that this security level is usually pre-configured in the domain identification information, such as "Level 2 Domain", "Level 3 Domain", or "Security Zone I" and "Security Zone II" as defined by power industry standards.

[0041] It should be noted that the combination method can be direct concatenation, such as connecting the three fields with underscores: "Operations Engineer_Highly Sensitive_Secondary Domain", or a more compact binary encoding can be used. The purpose is to use it as an index to quickly match in the rule base. The matching key can support exact matching, wildcard matching, or range matching. For example, "*_Highly Sensitive_Secondary Domain" means that no matter what the first permission level is, as long as the sensitivity level is "highly sensitive" and the target domain is "secondary domain", this rule will be matched.

[0042] This enables dynamic and automatic degradation of permissions during cross-domain processes, ensuring that when data enters a low-security domain, operation permissions are forcibly reduced to the range that matches the security requirements of that domain, fundamentally preventing high permissions from being illegally inherited or abused.

[0043] Step S103: Combine the second permission level, the identifier of the second security domain, the rule identifier, and the version number according to a preset encoding rule to generate a permission tag, and use a cryptographic hash function to calculate the combined hash value of the combined data composed of the content digest and the permission tag. Pack the combined hash value with the current timestamp and write it into the blockchain to receive the evidence certificate returned by the blockchain. In some embodiments, the step of combining the second permission level, the identifier of the second security domain, the rule identifier, and the version number according to a preset encoding rule to generate a permission tag includes: converting the second permission level, the identifier of the second security domain, the rule identifier, and the version number into string form respectively to obtain a first standardized string, a second standardized string, a third standardized string, and a fourth standardized string; concatenating the first standardized string, the second standardized string, the third standardized string, and the fourth standardized string in sequence according to a preset delimiter to generate a combined string; and encoding the combined string to obtain the permission tag. Specifically, to avoid ambiguity or format errors when concatenating different data types (integers, strings, and floating-point numbers), the four fields of the second permission level, the identifier of the second security domain, the rule identifier, and the version number are first converted into string form, and the four converted strings are respectively called the first standardized string, the second standardized string, the third standardized string, and the fourth standardized string. Next, the system concatenates these four standardized strings into a combined string in a fixed order, using a pre-defined delimiter (such as a character that will not appear in any field content, like "|" or ":"). The concatenation order can be: second permission level + delimiter + second security domain identifier + delimiter + rule identifier + delimiter + version number. After obtaining the combined string, the system needs to encode it to generate the final permission label. The encoded string is the final permission label.

[0044] For example, assuming the second permission level is "read-only", the second security domain identifier is "DOMAIN_B", the rule identifier is "R003", and the version number is "v1", then concatenating them will result in "read-only|DOMAIN_B|R003|v1".

[0045] It should be noted that common encoding methods include Base64, URL encoding, or directly using the raw string (if the delimiter is secure and the transmission environment is reliable). In this embodiment, Base64 encoding is preferred because it can convert any binary or special characters into an ASCII string containing only letters, numbers, and "+", " / ", and "=", which is both secure and convenient for carrying in HTTP headers or JSON fields.

[0046] By generating permission tags, the downgraded permission information is structurally bound to the target security domain and the rules adopted, making it easier to quickly identify the source and legitimacy of permissions during subsequent verification.

[0047] Please refer to Figure 2 In some embodiments, the step of using a cryptographic hash function to calculate the combined hash value of the combined data consisting of the content digest and the permission tag, packaging the combined hash value with the current timestamp, and writing it into the blockchain to receive the evidence returned by the blockchain includes steps S201 to S204: Step S201: Concatenate the content summary and the permission tag into combined data in a preset order, and call the cryptographic hash function to perform a hash operation on the combined data to obtain the combined hash value; In some embodiments, after generating the content digest and permission tags, these two data segments are concatenated into a single combined data set in a pre-agreed order (e.g., content digest first, then permission tags, or vice versa). During concatenation, the two strings can be directly joined sequentially without any separators, as the content digest and permission tags each have a fixed format or length, allowing the receiver to correctly split them. After concatenation, the system calls a cryptographic hash function (e.g., SM3 or SHA-256) to perform a hash operation on the combined data, calculating a fixed-length hash value, called the combined hash value.

[0048] Step S202: Assemble the combined hash value and the current timestamp into a notarized transaction, wherein the notarized transaction includes at least the combined hash value, the current timestamp, and the signature of the transaction initiator; In some embodiments, after obtaining the combined hash value, the system needs to store it together with the current timestamp on the blockchain to construct a notarization transaction. This notarization transaction contains at least three elements: first, the combined hash value that was just calculated; second, the current system timestamp (accurate to the second or millisecond, used to identify the time when notarization occurs); and third, the signature of the transaction initiator.

[0049] It should be noted that the transaction initiator is typically a security gateway or dedicated client responsible for data transmission within the first security domain. The device's private key is used to digitally sign the transaction content to prove that the notarized transaction was indeed initiated by the legitimate data sender, preventing forgery. In addition to these three required fields, the transaction can also include some optional metadata, such as the identifier of the first security domain and the packet sequence number, but these are not mandatory.

[0050] Step S203: Broadcast the evidence storage transaction to multiple consensus nodes of the blockchain network, and have each consensus node perform consensus verification on the evidence storage transaction; In some embodiments, after the notarized transaction is assembled, the system broadcasts it to multiple consensus nodes in the blockchain network. When the consensus nodes on the blockchain network receive the notarized transaction, they perform consensus verification on the transaction according to the consensus mechanism (such as PBFT, Raft, or PoA) pre-set by the blockchain system. The verification includes checking whether the transaction format is correct, whether the signature is valid, whether the length of the combined hash value meets the requirements, whether the timestamp is within a reasonable range (to prevent malicious early or late submissions), and whether there are problems such as double-spending or duplicate submissions.

[0051] It should be noted that a blockchain network typically consists of several independent consensus nodes that work together to maintain the same distributed ledger.

[0052] Step S204: After consensus verification is passed, the notarization transaction is written into the distributed ledger of the blockchain, and the transaction hash returned by the blockchain system is received as the notarization certificate.

[0053] In some embodiments, once a notarized transaction passes consensus verification, the consensus node packages it into a new block and appends it to the blockchain's distributed ledger. Due to the immutable nature of the blockchain, the notarized record is permanently stored after being written, and no one can delete or modify it. After successful writing, the blockchain system returns a transaction hash (TxHash) to the initiator. This transaction hash is the unique credential for this notarization, which can be understood as the notarized record's "identity card" on the blockchain. Upon receiving this transaction hash, the first security domain uses it as the notarization credential and subsequently repackages it along with the permission tag and the original data packet before sending it to the second security domain.

[0054] By binding the permission downgrade result with the content summary and storing it on the blockchain, the immutability and traceability of the permission tag and content summary are ensured, providing a reliable basis for subsequent verification by the recipient.

[0055] Step S104: Re-encapsulate the permission tag, the evidence storage certificate, and the transmission data packet into a new data entity, and send the data entity to the second security domain, so that after the second security domain verifies the evidence storage certificate in the received data entity, it allows access to the data entity according to the second permission level.

[0056] In some embodiments, re-encapsulating the permission tag, the evidence storage certificate, and the transmission data packet into a new data entity includes: converting the permission tag into a permission tag byte array and obtaining the permission tag length of the permission tag byte array; converting the evidence storage certificate into an evidence storage certificate byte array and obtaining the evidence storage certificate length of the evidence storage certificate byte array; combining the encapsulation protocol identifier, the version number of the downgrade rule, the permission tag length, and the evidence storage certificate length into an encapsulation header byte array according to a preset encapsulation header format; and concatenating the encapsulation header byte array, the permission tag byte array, the evidence storage certificate byte array, and the transmission data packet in sequence to generate the data entity. Specifically, firstly, the .getBytes() method in the programming language is called to convert the permission tag into a byte array, and the length of this byte array is recorded, called the permission tag length; then, the evidence storage certificate returned from the blockchain (i.e., the transaction hash string) is also converted into a byte array, and its length is recorded, called the evidence storage certificate length. Next, following the pre-agreed encapsulation header format, the following fields are written in sequence: encapsulation protocol identifier, downgrade rule version number, permission tag length, and evidence storage credential length. These fields are then concatenated in order to form an encapsulation header byte array. Finally, the four parts are concatenated in the order of "encapsulation header byte array + permission tag byte array + evidence storage credential byte array + original transmission data packet" to generate a new, complete data entity.

[0057] It should be noted that the encapsulation protocol identifier is a fixed magic number or protocol number, which is used by the receiver to identify the encapsulation format of the present invention, such as "0x5A3F".

[0058] By encapsulating and transmitting data in this way, permission constraints and evidence information flow along with the data, avoiding the control failure caused by the separation of permissions and data in traditional solutions.

[0059] Please refer to Figure 3 In some embodiments, the step of allowing access to the data entity according to the second permission level after the second security domain verifies the evidence in the received data entity includes steps S301 to S305: Step S301: After receiving the data entity, the second security domain parses the received data packet, the permission tag, and the evidence storage certificate from the data entity according to the same preset encapsulation header format as during encapsulation. In some embodiments, after a data entity is sent from a first security domain to a second security domain, the receiving gateway or security agent on the second security domain side first decapsulates the data entity according to the same encapsulation header format as the sender. Specifically, the first few bytes of the data entity are read to parse out the encapsulation protocol identifier, confirming that this is a data packet using the encapsulation format of this invention. Then, the version number of the downgrade rule, the length of the permission tag, and the length of the evidence storage certificate are read from the header fields. Based on the value of the permission tag length field, bytes of data of the corresponding length are extracted from the header and restored to the permission tag. Then, based on the value of the evidence storage certificate length field, bytes of data of the following length are extracted and restored to the evidence storage certificate. The remaining portion is the original received data packet (i.e., the data payload and its original header).

[0060] Step S302: Parse the identifiers of the second permission level and the second security domain from the permission tag; In some embodiments, after obtaining the permission tag, since the permission tag is generated at the sending end according to the format "second permission level|second security domain identifier|rule identifier|version number" (separator "|") and Base64 encoded, the receiving end first Base64 decodes the permission tag to obtain the original combined string, and then splits the string into four fields according to the same separator "|". The first field is the second permission level (e.g., "read-only"), and the second field is the identifier of the second security domain (e.g., "DOMAIN_B").

[0061] It should be noted that the receiving end also needs to check whether this second security domain identifier is consistent with its own domain identifier. If they are inconsistent, it means that the permission label may have been tampered with or sent to the wrong domain. In this case, access should be denied directly.

[0062] Step S303: Recalculate the content digest of the parsed received data packet to obtain the target content digest. Combine the target content digest with the parsed permission tag to obtain the combination result. Recalculate the combination result using the same cryptographic hash function to obtain the target combination hash value. In some embodiments, to verify whether data has been tampered with during transmission, the receiving end needs to recalculate the data payload in the decapsulated received data packet using the same hash function (e.g., SM3 or SHA-256) as the sending end, obtaining a content digest, called the target content digest. Then, this target content digest and the parsed permission tag are concatenated into a combined result in the same order as the sending end (the same assembly order as before). Next, the same cryptographic hash function is called to perform a hash operation on this combined result, obtaining a fixed-length hash value, called the target combined hash value. This target combined hash value represents the "digital fingerprint" calculated in real time by the receiving end based on the received data packet and permission tag.

[0063] Step S304: Using the evidence certificate as the query key, obtain the pre-stored combined hash value and the block timestamp of the block where the evidence certificate is located from the blockchain, and compare the target combined hash value with the pre-stored combined hash value. In some embodiments, the receiving end initiates a query request to the blockchain network using the evidence parsed from the data entity (i.e., the transaction hash returned by the blockchain) as the query key. The blockchain network, based on this transaction hash, searches for the corresponding evidence record in the distributed ledger and returns the combined hash value stored in that record, along with the timestamp at the time of writing. Since the data on the blockchain is read-only and immutable, this returned combined hash value is generally the original combined hash value stored by the first security domain before sending the data. Therefore, it is necessary to compare the target combined hash value calculated by the receiving end with the original combined hash value retrieved from the blockchain byte by byte.

[0064] Step S305: If the comparison is consistent and the difference between the block timestamp and the current time is within the preset validity period, the verification is successful, and the second security domain grants access permissions to the data payload in the received data packet according to the second permission level.

[0065] In some embodiments, if the two combined hash values ​​are completely identical, it indicates that the entire chain from the content digest to the permission tag to the data payload has not been tampered with; if the comparison results are inconsistent, it indicates that the data has been modified during transmission, and the receiving end should discard the data packet and record an alarm log. In addition to hash matching, the receiving end also needs to check whether the evidence storage timestamp retrieved from the blockchain is within the preset validity period. If the difference between the current system time and the evidence storage timestamp exceeds the validity period threshold, even if the hash comparison is consistent, it is considered a verification failure. Verification is considered successful only when both conditions are met: hash matching and the timestamp being within the validity period. At this time, the second security domain grants the corresponding access rights (e.g., allowing viewing but not modification or deletion) to the data payload in the received data packet according to the second permission level (e.g., "read-only") parsed from the permission tag.

[0066] It should be noted that the preset validity period can be configured uniformly by the system administrator, for example, set to 5 minutes or 10 minutes. This verification achieves access control and permission enforcement based on blockchain credentials within the target security domain, ensuring that only data entities that pass integrity verification and have valid permission tags can be accessed with downgraded permissions, thereby improving the overall security of power business data transmission across security domains in a closed loop.

[0067] This invention, through parsing transmitted data packets, can pre-identify key data attributes and visitor identities, laying the foundation for subsequent refined access control and avoiding security blind spots caused by blind transmission. By determining the first and second permission levels, it achieves dynamic and automatic permission degradation during cross-domain processes, ensuring that when data enters a lower security domain, operational permissions are forcibly narrowed to the range matching the security requirements of that domain, fundamentally preventing the unauthorized inheritance or abuse of high permissions. By generating permission tags, the downgraded permission information forms an inseparable structured binding with the target security domain and the adopted rules, facilitating rapid identification of the source and legitimacy of permissions during subsequent verification. By calculating combined hash values, it can cryptographically link data content and permission tags. The system establishes a strong connection between data and permissions to prevent individual tampering or stripping of content or permissions. Leveraging the immutability and timestamping properties of blockchain, it permanently stores the association between data content and permission tags, as well as the moment of degradation, providing authoritative verification for subsequent access and effectively resisting post-hoc repudiation or log forgery attacks. By encapsulating and transmitting data, permission constraints and evidence flow along with the data, avoiding the control failures caused by the separation of permissions and data in traditional solutions. Verification enables access control and permission enforcement based on blockchain credentials within the target security domain, ensuring that only data entities that pass integrity verification and have valid permission tags can be accessed with downgraded permissions, thus improving the overall security of power business data transmission across security domains in a closed loop.

[0068] like Figure 4 As shown, based on the above method embodiments, corresponding apparatus embodiments are provided; An embodiment of the present invention provides a secure transmission system for power business data oriented towards sensitive data, comprising: The first module 100 is used to obtain the content summary, sensitivity level and identity information of the access subject of the data packet when the data packet needs to be transmitted from the first security domain to the second security domain. The second module 200 is used to determine the first permission level of the access subject in the first security domain based on the identity information, and to match the second permission level, the first permission level and the sensitivity level in a preset rule base to determine the rule identifier and version number of the second permission level and the downgrade rule applicable to the second security domain. The third module 300 is used to combine the second permission level, the identifier of the second security domain, the rule identifier and the version number according to a preset encoding rule to generate a permission tag, and to use a cryptographic hash function to calculate the combined hash value of the combined data composed of the content digest and the permission tag, and to package the combined hash value with the current timestamp and write it into the blockchain to receive the evidence certificate returned by the blockchain. The fourth module 400 is used to repackage the permission tag, the evidence storage certificate, and the transmission data packet into a new data entity, and send the data entity to the second security domain, so that after the second security domain verifies the evidence storage certificate in the received data entity, it allows access to the data entity according to the second permission level.

[0069] In some embodiments, the third module 300 includes: The first unit is used to concatenate the content summary and the permission tag into combined data in a preset order, and call the cryptographic hash function to perform a hash operation on the combined data to obtain a combined hash value. The second unit is used to assemble the combined hash value and the current timestamp into a notarized transaction, wherein the notarized transaction includes at least the combined hash value, the current timestamp, and the signature of the transaction initiator; The third unit is used to broadcast the evidence storage transaction to multiple consensus nodes of the blockchain network, and each consensus node performs consensus verification on the evidence storage transaction. The fourth unit is used to write the notarized transaction into the distributed ledger of the blockchain after the consensus verification is passed, and to receive the transaction hash returned by the blockchain system as notarized proof.

[0070] It is understood that the above-described device embodiments correspond to the method embodiments of the present invention, and can implement the secure transmission method for power business data oriented towards sensitive data provided by any of the above-described method embodiments of the present invention.

[0071] It should be noted that the device embodiments described above are merely illustrative, and some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Furthermore, in the accompanying drawings of the device embodiments provided by this invention, the connection relationships between modules indicate that they have communication connections, which can specifically be implemented as one or more communication buses or signal lines. Those skilled in the art can understand and implement this without any creative effort.

[0072] Based on the above embodiments of the secure transmission method for sensitive power business data, another embodiment of the present invention provides a terminal device, which includes a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor. When the processor executes the computer program, it implements the secure transmission method for sensitive power business data according to any embodiment of the present invention.

[0073] For example, in this embodiment, the computer program can be divided into one or more modules, which are stored in the memory and executed by the processor to complete the present invention. The one or more modules may be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of the computer program in the terminal device.

[0074] The terminal device may be a desktop computer, laptop, handheld computer, or cloud server, etc. The terminal device may include, but is not limited to, a processor and a memory.

[0075] The processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor. The processor is the control center of the terminal device, connecting all parts of the terminal device via various interfaces and lines.

[0076] Based on the above-described method embodiments, another embodiment of the present invention provides a computer-readable storage medium including a stored computer program, wherein, when the computer program is executed, it controls the device where the computer-readable storage medium is located to execute the secure transmission method for power business data oriented towards sensitive data as described in any of the above-described method embodiments of the present invention.

[0077] The modules / units integrated in the device / terminal equipment, if implemented as software functional units and sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the above embodiments of the present invention can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, a recording medium, a USB flash drive, a portable hard drive, a magnetic disk, an optical disk, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium, etc.

[0078] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications are also considered to be within the scope of protection of the present invention.

Claims

1. A method for secure transmission of power business data oriented towards sensitive data, characterized in that, include: When a data packet needs to be transmitted from the first security domain to the second security domain, the content summary, sensitivity level, and identity information of the accessing subject of the data packet are obtained. Based on the identity information, the first permission level of the access subject in the first security domain is determined. Based on the security level of the second security domain, the first permission level, and the sensitivity level, a match is made in a preset rule base to determine the second permission level applicable to the second security domain, the rule identifier and version number of the downgrade rule. The second permission level, the identifier of the second security domain, the rule identifier, and the version number are combined according to a preset encoding rule to generate a permission tag. A cryptographic hash function is used to calculate the combined hash value of the combined data consisting of the content digest and the permission tag. The combined hash value is packaged with the current timestamp and written into the blockchain to receive the evidence returned by the blockchain. The permission tag, the evidence storage certificate, and the transmission data packet are repackaged into a new data entity, and the data entity is sent to the second security domain. After the second security domain verifies the evidence storage certificate in the received data entity, it allows access to the data entity according to the second permission level.

2. The method for secure transmission of power business data oriented towards sensitive data according to claim 1, characterized in that, The step of calculating a combined hash value of the combined data consisting of the content digest and the permission tag using a cryptographic hash function, packaging the combined hash value with the current timestamp, and writing it into the blockchain to receive the evidence returned by the blockchain includes: The content summary and the permission tag are concatenated into combined data in a preset order, and the combined data is hashed by calling the cryptographic hash function to obtain the combined hash value. The combined hash value and the current timestamp are assembled into a notarized transaction, wherein the notarized transaction includes at least the combined hash value, the current timestamp, and the signature of the transaction initiator; The notarized transaction is broadcast to multiple consensus nodes in the blockchain network, and each consensus node performs consensus verification on the notarized transaction. After consensus verification is passed, the notarized transaction is written into the distributed ledger of the blockchain, and the transaction hash returned by the blockchain system is received as the notarized certificate.

3. The method for secure transmission of power business data oriented towards sensitive data according to claim 1, characterized in that, The step of obtaining the content digest, sensitivity level, and identity information of the accessing subject of the transmitted data packet includes: A preset hash function is invoked to calculate the data payload in the transmitted data packet, thereby generating the content digest; Extract the identity information of the accessing subject from the metadata header of the transmitted data packet; The initial sensitivity level tag is read from the metadata header to obtain the first sensitivity level. The content summary is used as an index to query the preset sensitive data feature library. If a match is found, the second sensitivity level is obtained. The first sensitivity level and the second sensitivity level are comprehensively evaluated according to the preset security policy to determine the sensitivity level.

4. The method for secure transmission of power business data oriented towards sensitive data according to claim 3, characterized in that, Determining the first permission level of the access subject in the first security domain based on the identity information includes: The subject identifier in the identity information is queried through a preset role mapping table to determine the role category of the accessing subject in the system; Using the role category as the key, query the permission mapping table of the first security domain to obtain the original permission set; The original permission set is filtered according to preset dynamic permission constraint rules, and the filtered permission set is determined as the first permission level.

5. The method for secure transmission of power business data oriented towards sensitive data according to claim 1, characterized in that, The step of matching the second security domain's security level, the first permission level, and the sensitivity level in a preset rule base to determine the rule identifier and version number applicable to the second permission level and the downgrade rule for the second security domain includes: Combine the first permission level, the sensitivity level, and the security level of the second security domain into a permission downgrade query key; Using the permission downgrade query key as an index, a matching operation is performed in a preset rule base, wherein the rule base contains multiple rule entries; If a unique first rule entry is matched, the downgraded permission level in the first rule entry is determined as the second permission level, and the rule identifier and the version number of the first rule entry are extracted. If multiple second rule entries are matched, the third rule entry with the highest priority is determined according to the preset priority field in each second rule entry, and the corresponding downgraded permission level in the third rule entry is extracted and determined as the second permission level, the rule identifier and the version number.

6. The method for secure transmission of power business data oriented towards sensitive data according to claim 1, characterized in that, The step of combining the second permission level, the identifier of the second security domain, the rule identifier, and the version number according to a preset encoding rule to generate a permission tag includes: The second permission level, the identifier of the second security domain, the rule identifier, and the version number are converted into string form respectively to obtain the first standardized string, the second standardized string, the third standardized string, and the fourth standardized string; The first, second, third, and fourth standardized strings are concatenated in sequence according to the preset delimiter to generate a combined string; The combined string is encoded to obtain the permission tag.

7. The method for secure transmission of power business data oriented towards sensitive data according to claim 1, characterized in that, The step of re-encapsulating the permission tag, the evidence storage certificate, and the transmission data packet into a new data entity includes: Convert the permission tags into a permission tag byte array and obtain the permission tag length of the permission tag byte array; Convert the evidence storage certificate into an evidence storage certificate byte array, and obtain the evidence storage certificate length of the evidence storage certificate byte array; According to the preset encapsulation header format, the encapsulation protocol identifier, the version number of the downgrade rule, the length of the permission tag, and the length of the evidence storage certificate are combined into an encapsulation header byte array; The data entity is generated by sequentially concatenating the encapsulated header byte array, the permission tag byte array, the evidence storage byte array, and the transmission data packet.

8. The method for secure transmission of power business data oriented towards sensitive data according to claim 1, characterized in that, The step of enabling the second security domain to access the data entity according to the second permission level after verifying the evidence stored in the received data entity includes: After receiving the data entity, the second security domain parses the received data packet, the permission tag, and the evidence storage certificate from the data entity according to the same preset encapsulation header format as during encapsulation. The identifiers of the second permission level and the second security domain are parsed from the permission tags; The content digest of the parsed received data packet is recalculated to obtain the target content digest. The target content digest is combined with the parsed permission tag to obtain the combined result. The combined result is then recalculated using the same cryptographic hash function to obtain the target combined hash value. Using the evidence certificate as the query key, retrieve the pre-stored combined hash value and the block timestamp of the block where the evidence certificate is located from the blockchain, and compare the target combined hash value with the pre-stored combined hash value. If the comparison matches and the difference between the block timestamp and the current time is within a preset validity period, the verification is successful, and the second security domain grants access to the data payload in the received data packet according to the second permission level.

9. A secure transmission system for power business data oriented towards sensitive data, characterized in that, include: The first module is used to obtain the content summary, sensitivity level, and identity information of the accessing subject of the data packet when the data packet needs to be transmitted from the first security domain to the second security domain. The second module is used to determine the first permission level of the access subject in the first security domain based on the identity information, and to match the second permission level, the first permission level and the sensitivity level in a preset rule base to determine the rule identifier and version number of the second permission level and the downgrade rule applicable to the second security domain. The third module is used to combine the second permission level, the identifier of the second security domain, the rule identifier, and the version number according to a preset encoding rule to generate a permission tag, and to use a cryptographic hash function to calculate the combined hash value of the combined data composed of the content digest and the permission tag. The combined hash value is then packaged with the current timestamp and written into the blockchain to receive the evidence returned by the blockchain. The fourth module is used to repackage the permission tag, the evidence storage certificate, and the transmission data packet into a new data entity, and send the data entity to the second security domain, so that after the second security domain verifies the evidence storage certificate in the received data entity, it allows access to the data entity according to the second permission level.

10. The secure transmission system for power business data oriented towards sensitive data according to claim 9, characterized in that, The third module includes: The first unit is used to concatenate the content summary and the permission tag into combined data in a preset order, and call the cryptographic hash function to perform a hash operation on the combined data to obtain a combined hash value. The second unit is used to assemble the combined hash value and the current timestamp into a notarized transaction, wherein the notarized transaction includes at least the combined hash value, the current timestamp, and the signature of the transaction initiator; The third unit is used to broadcast the evidence storage transaction to multiple consensus nodes of the blockchain network, and each consensus node performs consensus verification on the evidence storage transaction. The fourth unit is used to write the notarized transaction into the distributed ledger of the blockchain after the consensus verification is passed, and to receive the transaction hash returned by the blockchain system as notarized proof.

Images