Multi-level encryption strategy-based power data access control method and device

Abstract

The application provides a power data access control method and device with a multi-level encryption strategy. The method comprises: establishing a platform root key, a role key derived based on a role identifier, and a homomorphic encryption public-private key pair bound with a sensitive field in an encryption engine, and mapping the keys to corresponding power data fields; performing first layer encryption on a power data block to be stored using the platform root key, performing second layer encryption on a field set belonging to a corresponding role access level using the role key, and performing third layer encryption on a sensitive field using a homomorphic encryption public key; distributing a data key set to a computing node, so that the computing node performs decryption or ciphertext computation on the encrypted power data to obtain target data; re-encrypting the target data using the role key, and providing the re-encrypted target data to a requester carrying a role identifier. The application can balance fine-grained permission isolation and online ciphertext computation data security access.

Description

Technical Field

[0001] This application relates to the field of data encryption technology, and in particular to a power data access control method and apparatus with a multi-level encryption strategy. Background Technology

[0002] As the digital transformation of the power grid deepens, large-scale heterogeneous data continues to be generated by business systems such as dispatching, generation, transmission and distribution, and the electricity market. Electricity data is not only crucial for ensuring the safe operation and precise dispatch of the power grid, but also holds considerable commercial value in scenarios such as load forecasting, equipment health management, and energy trading. Documents successively issued by regulatory authorities at all levels have clearly put forward the principle of secure data circulation—"raw data not leaving the domain, data usable but not visible"—imposing higher compliance requirements on power companies in the process of data sharing and trading.

[0003] With the formation of the data element market, power grid companies need to establish controllable and reliable data flow channels among multiple departments within the group and external research institutions and equipment manufacturers. Different entities have significantly different needs regarding data granularity and sensitivity, requiring both consistency in key business reporting and strict restriction of unauthorized access. Therefore, the platform urgently needs a multi-layered encrypted access control mechanism that combines role-based permissions, field sensitivity, and encrypted computation capabilities to support collaborative analysis and modeling without exposing plaintext.

[0004] Existing technologies generally employ single-layer or few-layer encryption methods: First, database disk-level whole-database encryption only provides static protection and cannot meet fine-grained authorization requirements; second, attribute-based access control (ABAC) typically relies on a single key or access token, and changes in roles require the entire key to be reissued, resulting in high maintenance costs; third, while column-level or row-level transparent encryption can hide sensitive content by field, decryption is still required when cross-domain statistics or machine learning are needed, making it unable to collaborate with homomorphic encryption, differential privacy, and other encrypted computing technologies. Furthermore, most solutions do not link role-derived keys with dynamic usage metering, making it difficult to achieve real-time control or traceability of data usage.

[0005] Existing technical solutions have at least the following drawbacks: First, they lack support for encrypted operations such as homomorphic encryption, meaning that once data is encrypted, it loses its online computing capability; second, the binding between role or field authorization and encryption level is unclear, requiring large-scale re-encryption when roles are adjusted, affecting system availability; third, the coexistence of multiple independent key systems makes unified derivation and rotation impossible, easily leading to key leakage risks; and finally, the current mechanism focuses on static authorization and lacks dynamic circuit breaker capabilities linked to usage measurement and call thresholds, making it difficult to meet the contract billing requirements of data transaction scenarios. Summary of the Invention

[0006] In view of this, embodiments of this application provide a power data access control method and apparatus with a multi-layered encryption strategy to solve the data access control problem in the prior art that cannot simultaneously take into account fine-grained permission isolation and encrypted computation.

[0007] A first aspect of this application provides a power data access control method with a multi-layered encryption strategy, comprising: establishing a platform root key, a role key derived from a role identifier, and a homomorphic encryption public-private key pair bound to sensitive fields in an encryption engine, and mapping the keys to corresponding power data fields; performing a first layer of encryption on the power data block to be stored using the platform root key, performing a second layer of encryption on a set of fields belonging to the access level of the corresponding role using the role key, and performing a third layer of encryption on the sensitive fields using the homomorphic encryption public key; receiving a power data access request carrying a role identifier and completing authentication, and assembling a data key set containing the role key and the homomorphic encryption private key when authentication is successful; distributing the data key set to computing nodes, enabling computing nodes to perform decryption or encrypted computation on the encrypted power data to obtain target data; re-encrypting the target data using the role key, and providing the re-encrypted target data to the requester carrying the role identifier, so that the requester can complete access to the power data.

[0008] A second aspect of this application provides a power data access control device with a multi-layered encryption strategy, comprising: an establishment module, configured to establish a platform root key, a role key derived from a role identifier, and a homomorphic encryption public-private key pair bound to sensitive fields in an encryption engine, and map the keys to corresponding power data fields; an encryption module, configured to perform a first layer of encryption on the power data block to be stored using the platform root key, perform a second layer of encryption on a set of fields belonging to the access level of the corresponding role using the role key, and perform a third layer of encryption on sensitive fields using the homomorphic encryption public key; an assembly module, configured to receive a power data access request carrying a role identifier and complete authentication, and assemble a data key set containing the role key and the homomorphic encryption private key when authentication is successful; a distribution module, configured to distribute the data key set to computing nodes, enabling computing nodes to perform decryption or encrypted computation on the encrypted power data to obtain target data; and a re-encryption module, configured to re-encrypt the target data using the role key and provide the re-encrypted target data to the requester carrying the role identifier, so that the requester can complete access to the power data.

[0009] A third aspect of this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described method.

[0010] A fourth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the above-described method.

[0011] The above-described technical solutions adopted in the embodiments of this application can achieve the following beneficial effects:

[0012] This invention establishes a platform root key, a role key derived from a role identifier, and homomorphic encryption public-private key pairs bound to sensitive fields within the encryption engine, mapping these keys to corresponding power data fields. The platform root key performs a first layer of encryption on the power data block to be stored; the role key performs a second layer of encryption on the set of fields belonging to the corresponding role's access level; and the homomorphic encryption public key performs a third layer of encryption on the sensitive fields. The system receives power data access requests carrying role identifiers and completes authentication. Upon successful authentication, a data key set containing the role key and the homomorphic encryption private key is assembled. The data key set is distributed to computing nodes, enabling them to decrypt or perform encrypted computation on the encrypted power data to obtain the target data. The target data is then re-encrypted using the role key, and the re-encrypted target data is provided to the requester carrying the role identifier, allowing the requester to access the power data. This application achieves both fine-grained access control and secure data access through online encrypted computation. Attached Figure Description

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

[0014] Figure 1 This is a flowchart illustrating the power data access control method with a multi-layered encryption strategy provided in an embodiment of this application.

[0015] Figure 2 This is a schematic diagram of the structure of the power data access control device with a multi-level encryption strategy provided in the embodiments of this application;

[0016] Figure 3 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

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

[0018] Existing technologies typically employ database-wide encryption, column-level transparent encryption, or attribute-based access control (ABAC) to protect power data. However, database-wide encryption only provides static protection, column-level encryption still requires decryption during collaborative analysis, and ABAC schemes require large-scale key retransmission once role or field permissions are adjusted, making it difficult to balance fine-grained isolation, computational performance, and key management burden. The result is: coarse-grained permissions, limited encrypted computation, and complex key rotation.

[0019] Based on the aforementioned shortcomings, the technical problem addressed by this application is that existing technologies cannot simultaneously meet the data access control requirements of fine-grained access control and encrypted computation. To solve this problem, this application proposes a multi-layered encryption strategy for power data access control. The core technical solution of this application includes:

[0020] A hierarchical key system is established within the encryption engine, consisting of a platform root key, a role-derived key, and a homomorphic key pair for sensitive fields. Each key index is then mapped to its corresponding data field.

[0021] The data block is encrypted using a root key as the first layer of encryption, the role field set is encrypted using a role key as the second layer of encryption, and the sensitive fields are encrypted using a homomorphic public key as the third layer of encryption, forming a hierarchical and authorizable ciphertext storage.

[0022] After user authentication, a data key set of "role key + homomorphic private key" is dynamically assembled and securely distributed to the computing node to complete decryption or encrypted operation in a trusted execution environment;

[0023] The computing node re-encrypts the result using the role key and returns it, achieving end-to-end encrypted transmission.

[0024] The aforementioned technical solution enables the platform to achieve bidirectional isolation at the role and field levels without exposing plaintext, and supports online encrypted operations such as homomorphic computation, further simplifying the key derivation and rotation process. The resulting technical effect is: balancing fine-grained access control with secure data access through online encrypted computation, while reducing key management complexity and meeting the compliance requirements of power data that ensure "raw data does not leave the domain and data is usable but not visible."

[0025] The technical solution of this application will now be described in detail with reference to the accompanying drawings and specific embodiments.

[0026] Figure 1 This is a flowchart illustrating the power data access control method with a multi-layered encryption strategy provided in an embodiment of this application. Figure 1 As shown, the power data access control method of this multi-layered encryption strategy may specifically include:

[0027] S101, establish a platform root key, a role key derived from the role identifier, and a homomorphic encryption public-private key pair bound to sensitive fields in the encryption engine, and map the keys to the corresponding power data fields;

[0028] S102, use the platform root key to perform the first layer of encryption on the power data block to be stored, use the role key to perform the second layer of encryption on the set of fields belonging to the corresponding role access level, and use the homomorphic encryption public key to perform the third layer of encryption on the sensitive fields.

[0029] S103, receive the power data access request carrying the role identifier and complete the authentication, and assemble a data key set containing the role key and the homomorphic encryption private key when the authentication is successful;

[0030] S104, Distribute a set of data keys to the computing nodes so that the computing nodes can perform decryption or encrypted computation on the encrypted power data to obtain the target data;

[0031] S105, the target data is re-encrypted using the role key, and the re-encrypted target data is provided to the requester carrying the role identifier so that the requester can complete the access to the power data.

[0032] In some embodiments, a platform root key, a role key derived from a role identifier, and a homomorphic encryption public-private key pair bound to sensitive fields are established in the encryption engine, and the keys are mapped to the corresponding power data fields, including:

[0033] The hardware security module calls a random number generator to generate the platform root key and registers the root key index.

[0034] Using a preset key derivation function, the corresponding role key is generated with the platform root key and role identifier as input, and the role key index is registered.

[0035] For the power data field marked as a sensitive field, the homomorphic encryption parameter generation algorithm is invoked to generate a homomorphic encryption public-private key pair and register the homomorphic key index;

[0036] The mapping relationship between the power data field identifier and the root key index, role key index and homomorphic key index is recorded in the metadata storage table to complete the mapping of power data fields to multi-level keys.

[0037] Specifically, in this embodiment, the power data secure circulation platform deploys an encryption engine, a hardware security module (HSM), a metadata management component, and a user management component. The encryption engine is responsible for uniformly invoking cryptographic primitives and maintaining a multi-layered key system; the HSM provides high-entropy random numbers and key-level protection; the metadata management component is responsible for recording field-key mappings; and the user management component stores role identifiers and provides derived parameters to the encryption engine.

[0038] First, the platform root key K0 is generated using the HSM's true random number generator. After generation, K0 is stored internally in HSM in plaintext and never moduloed. External systems only obtain the root key index idx0 returned by HSM. idx0 is written into the root key record in the key repository for subsequent derivation and auditing.

[0039] Secondly, after obtaining the role identifier RID returned by the user management component, the system calls the key derivation function KDF built into the encryption engine. KDF takes K0 and RID as input, performs HMAC-SHA256 iterative calculation to generate the role key K_RID, and returns the role key index idx_RID. K_RID is imported into the erasable memory area of ​​the encryption engine in ciphertext form. Simultaneously, a new role key record is added to the key store, which only stores idx_RID and the bound RID.

[0040] Furthermore, for power data columns marked as sensitive fields by the platform, such as "avg_load" or "user_profile", the encryption engine calls a homomorphic encryption parameter generation algorithm to create a homomorphic public key pk_i and a homomorphic private key sk_i with security parameters (e.g., polynomial order 4096, modulus bit length 218, etc.). Immediately after generation, the homomorphic key index idx_HE_i is registered, and sk_i is sealed and stored using an HSM, exposing pk_i and idx_HE_i only to the compute nodes.

[0041] Subsequently, the metadata management component writes four binding information entries to the field table for each data field: field identifier FID, root key index idx0, role key index idx_RID, and homomorphic key index idx_HE_i. When a field belongs to neither a specific role nor is it a sensitive field, the corresponding index entry is set to null to indicate that this layer is not in effect. After the field table forms or updates the mapping, it triggers an event to notify the encryption engine to cache the latest mapping.

[0042] For example, the table T_meter contains the fields meter_id, substation_code, avg_load, and ts, where avg_load is marked as a high-sensitivity field. The role identifier for the "Load Analyst" is RID_OP. The platform writes idx0 generated by K0 into the root key column of the four fields; it writes the role key idx_RID_OP into meter_id and substation_code, and the homomorphic key idx_HE_load into avg_load, while retaining its null role key value; for ts, only idx0 is retained. Regardless of subsequent role changes or field policy adjustments, the field-key mapping table can be revised incrementally to ensure that the encryption level and permission view evolve synchronously.

[0043] Through the implementation of the above embodiments, this embodiment fully discloses the generation, derivation, registration and field mapping process of multi-layer keys, providing clear key indexes and calling paths for subsequent three-layer encryption, encrypted state calculation and result re-encryption stages, ensuring that the platform can achieve fine-grained data access control at both the role level and field level.

[0044] In some embodiments, the platform root key is used to perform a first layer of encryption on the power data block to be stored, a role key is used to perform a second layer of encryption on the set of fields belonging to the corresponding role access level, and a homomorphic encryption public key is used to perform a third layer of encryption on sensitive fields, including:

[0045] Before writing the data, the power data to be stored is divided into fragments according to the preset block size, and the symmetric encryption algorithm is called in the encryption engine to encrypt each data block with the platform root key to obtain the first layer of ciphertext blocks.

[0046] Based on the field-role mapping relationship, the set of fields belonging to the target role's access level is retrieved within the first-level ciphertext block, and the encryption algorithm is called in the encryption engine to encrypt the set of fields with the corresponding role key to generate the second-level ciphertext field;

[0047] For the field value marked as a sensitive field, the encryption function in the homomorphic encryption algorithm is called to encrypt the sensitive field with the homomorphic encryption public key, generating a third-layer homomorphic ciphertext field;

[0048] The first-level ciphertext block, the second-level ciphertext field, and the third-level homomorphic ciphertext field are combined and submitted to the data management module for storage.

[0049] Specifically, this embodiment elaborates on the three-layer encryption link in the power data writing process. First, the key technical features and implementation methods involved in this link are explained: First, a block-based fragmentation mechanism is introduced to ensure that large-capacity power data is divided into fixed-size blocks, facilitating unified block-level encryption using the platform's root key; second, a field-role mapping index is constructed, allowing the platform to quickly locate fields belonging to specific role access levels in pure ciphertext without decrypting the entire block; third, column-level homomorphic encryption technology is adopted to directly generate encrypted representations for field values ​​marked as sensitive, allowing subsequent aggregation or training to be completed in an encrypted environment. These three features are uniformly orchestrated by the encryption engine, sequentially executing root key encryption, role key encryption, and homomorphic key encryption operations, and are persistently stored by the data management module after completion.

[0050] In actual implementation, the platform first receives the power dataset to be written. Before writing, the encryption engine divides the data stream into contiguous blocks of 16MB each according to system-level parameters. The encryption engine calls the built-in AES-256-GCM algorithm to encrypt each data block using the platform root key K0, generating the first-level ciphertext block cipher_blk. This operation is completed in a pipeline manner within the encryption engine, and the random vector and authentication tag generated during the encryption process are cached together with cipher_blk.

[0051] Subsequently, the encryption engine locates the field offset segment belonging to the target role in the metadata associated with cipher_blk based on the field-role mapping index. For example, the field set corresponding to the role "Operations Engineer" includes meter_id and substation_code. The encryption engine extracts the binary fragments of these fields in cipher_blk, calls the AES-256-GCM algorithm, and encrypts them again with the role key K_RID, outputting the second-layer ciphertext field cipher_role. The cipher_role ciphertext is then replaced back in place at the corresponding position in cipher_blk, while recording the encryption identifier for read / write parsing.

[0052] For the avg_load field marked as high-sensitivity, the system pre-configures a homomorphic public key pk_load for it. Before reading the plaintext value of this field, the encryption engine calls the Encrypt function of the homomorphic encryption library to perform polynomial encoding and modulo operation on the field value using pk_load, directly generating the third-level homomorphic ciphertext field cipher_HE. cipher_HE no longer participates in role key encryption but is appended to the end of cipher_blk as an independent column, with its starting offset and length synchronously registered in the metadata.

[0053] After all three layers of encryption are completed, the encryption engine combines cipher_blk, cipher_role, and cipher_HE into the final ciphertext unit. During the combination process, the engine constructs block-level header information, which includes the root key index idx0, the role key index idx_RID, and the homomorphic key index idx_HE_load, and writes this information to the version number in the field-key mapping table. The final ciphertext unit is submitted to the data management module via a zero-copy channel. This module is responsible for persisting it to columnar storage and updating the field-key mapping entries in the metadata table.

[0054] Through the implementation of the above embodiments, this embodiment completes three-layer encryption processing of power data at the block level, role level, and sensitive field level during the data writing stage, ensuring that any subsequent key rotation or permission change can take effect independently, and laying the key and storage foundation for online encrypted calculation.

[0055] In some embodiments, receiving a power data access request carrying a role identifier and completing authentication, and assembling a data key set containing a role key and a homomorphic encrypted private key upon successful authentication, includes:

[0056] The communication management module receives power data access requests containing role identifiers in a two-way authenticated secure channel.

[0057] The user management module calls the authentication process to verify the role identifier and generates session credentials after successful verification.

[0058] In the encryption engine, the role key index is retrieved based on the role identifier and the corresponding role key is loaded. At the same time, the corresponding homomorphic encryption private key is retrieved and loaded based on the sensitive field identifier to be accessed.

[0059] The role key and the homomorphic encrypted private key are encapsulated into a data key set, and the data key set is associated with the session credentials and then output to the operator scheduling module.

[0060] Specifically, this embodiment describes the key distribution stage in the power data access process. First, the key technical features and implementation methods of this stage are explained: First, the platform establishes a trusted communication foundation between the client and the central node through a two-way authentication secure channel, ensuring that role identifiers and subsequent key materials are protected from man-in-the-middle tampering; Second, the user management module's authentication process is decoupled from the role key repository, and the authentication result is passed to the encryption engine through session credentials, achieving layered isolation between identity authentication and key invocation; Third, the data key set encapsulation mechanism binds role keys and homomorphic private keys to the same session context, thereby precisely controlling the key lifecycle on the operator scheduling module side.

[0061] In actual operation, the accessing client first initiates a TLS 1.3 handshake with the communication management module, filling in the role identifier RID_OP in the ClientHello extended field of the handshake. After verifying the peer's certificate, the communication management module establishes a two-way encrypted channel. Subsequently, the client submits a power data access request through this channel, which includes the target dataset identifier T_meter and the field list {meter_id, avg_load}.

[0062] Furthermore, upon receiving the request, the user management module invokes its internal OAuth2 authentication process to retrieve the account status and permission policy corresponding to RID_OP. After successful authentication, the user management module generates a session credential Token_OP with a validity period of two hours and passes the Token_OP along with RID_OP to the encryption engine.

[0063] Furthermore, the encryption engine queries the key repository based on RID_OP, locates the role key index idx_RID_OP, and loads the role key K_RID_OP into the controlled memory area. Simultaneously, it parses the field list and finds that avg_load has been marked as a sensitive field in the field-key mapping table, corresponding to the homomorphic key index idx_HE_load. The engine calls the HSM interface to decapsulate the homomorphic private key sk_load and loads it into the same memory area. At this point, the role key K_RID_OP and the homomorphic private key sk_load are jointly encapsulated into the data key set KeySet_OP.

[0064] Furthermore, the encryption engine writes KeySet_OP and Token_OP into the session context, forming a <Token_OP, KeySet_OP> pair, and pushes it to the operator scheduling module via the internal message bus. The operator scheduling module holds a read-only handle to KeySet_OP and can trigger key erasure immediately after the task is completed, ensuring that the residence time of key materials in RAM is controlled.

[0065] Through the implementation of the above embodiments, this embodiment discloses the complete implementation details from secure channel establishment and role authentication to data key set encapsulation and distribution, and demonstrates in detail the collaborative relationship and operation sequence of key technical features, providing secure and reliable key support for subsequent ciphertext computation tasks.

[0066] In some embodiments, a set of data keys is distributed to computing nodes, enabling the computing nodes to perform decryption or cryptographic computation on encrypted power data to obtain target data, including:

[0067] The data key set is distributed to the target computing node through the established secure session via the communication management module;

[0068] Under the scheduling instructions of the operator scheduling module, the computing node verifies its own identity based on the received session credentials and loads the data key set into the trusted execution environment;

[0069] When the role key corresponding to the field to be processed is encrypted, the symmetric or asymmetric decryption algorithm in the encryption engine is called to decrypt the corresponding field with the role key;

[0070] When the field to be processed corresponds to homomorphic encrypted ciphertext, the homomorphic operation interface is called to complete the calculation of the corresponding field in encrypted state;

[0071] The results of each field obtained through decryption or encrypted computation are merged to form the target data, and the data key set is cleared from the trusted execution environment after the computation is completed.

[0072] Specifically, this embodiment describes the process of issuing and using data key sets. Key technical features of this process include: first, key issuance within a secure session, ensuring that key materials are transmitted only in encrypted channels; second, loading of a trusted execution environment, ensuring that role keys and homomorphic private keys are used in isolated memory and controlled by hardware instruction sets; third, a hybrid pipeline of decryption and encrypted operations, using symmetric or asymmetric decryption for the encrypted fields of role keys, and directly calling homomorphic operators to complete operations on homomorphic ciphertext fields; and fourth, immediate key clearing upon task completion, synchronously erasing trusted memory through zeroing instructions and key handle revocation mechanisms to prevent subsequent processes from stealing the keys. The specific implementation steps are as follows:

[0073] First, the communication management module has pre-established a TLS tunnel with the target computing node. Upon receiving the <TokenOP, KeySetOP> pair, the operator scheduling module pushes KeySetOP to the node via the TLS tunnel, along with TokenOP for authentication. The node-side cryptographic engine parses TokenOP in its local security processor, compares it with the central node's signing public key to complete verification, and then loads KeySetOP into the Int el SGX-based security zone.

[0074] Further, during task execution, the node first locates the fields `meter_id` and `substation_code`, which are encrypted using the role key. The encryption engine calls the AES256GCM decryption interface, using the role key `KRIDOP` and the random vector stored in the ciphertext header to decrypt and recover the plaintext fields. The node then processes the sensitive field `avg_load`, which is homomorphic ciphertext. The encryption engine directly calls the `EvalSum` and `EvalScale` operators from the CKKS library to perform segment summation and scaling operations in encrypted form, producing the homomorphic result `cipherSum`. `cipherSum` can participate in subsequent merging without decryption.

[0075] Furthermore, after all fields have been calculated, the node writes the plaintext meter_id, substation_code, and homomorphic result cipherSum to the output buffer, forming the target data RecordOP. After confirming that RecordOP has been written to the disk snapshot, the operator scheduling module calls the encryption engine to trigger key erasure. The engine executes the combined instructions Me msetZero and EEXIT to forcibly clear KRIDOP and skload from the secure area and destroy the KeySetOP handle. Finally, the communication management module sends a "key set cleared" status code to the central node, ensuring a complete closed loop in the audit chain.

[0076] Through the above embodiments, the platform realizes a closed-loop end-to-end process of key distribution, authentication, trusted loading, hybrid decryption-encrypted computation, and instant key clearing, ensuring that role keys and homomorphic private keys only exist briefly in the trusted environment, enabling computing nodes to securely output target data after permission isolation and encrypted computation processing.

[0077] In some embodiments, re-encrypting the target data using a role key includes:

[0078] Generate a one-time random number as the encryption vector in the encryption engine;

[0079] A symmetric encryption algorithm is invoked to perform encryption operations on the target data based on the role key and encryption vector, resulting in re-encrypted ciphertext.

[0080] The re-encrypted ciphertext, encryption vector, and target data identifier are encapsulated into a ciphertext package and written into the log management module to register the key index and timestamp;

[0081] The communication management module sends a encrypted packet to the requester carrying the role identifier in the original session channel.

[0082] Specifically, this embodiment discloses in detail the technical solution of "re-encrypting target data using role keys". First, it explains the technical features and implementation methods of the solution, and then illustrates it with a typical process example.

[0083] First, to prevent ciphertext duplication under the same role key for different data packets, the encryption engine calls the True Random Number Generator (TRNG) integrated within the Hardware Security Module (HSM) before each re-encryption to generate a 96-bit random byte sequence nonce. The TRNG complies with GB / T18336 and NISTSP800-90B randomness detection requirements, ensuring the quality of the entropy source. The nonce is only valid within the current session and is written to the encryption engine's isolation register immediately after generation.

[0084] In some examples, the encryption algorithm uses AES-256-GCM mode, and the key material is the role key KRID_x bound during the user login phase. The encryption engine calls the AEAD_Encrypt interface, taking {KRID_x, nonce, target data Record_x} as input, and outputs the re-encrypted ciphertext cipher_x and the authentication tag tag_x, where tag_x is 128 bits long and used for integrity verification. KRID_x remains in the encryption engine's controlled buffer after encryption until it is erased after the ciphertext packet is successfully sent.

[0085] To facilitate downstream parsing and auditing, the platform defines a unified TLV (Type-Length-Value) encapsulation format: the Type field identifies the data item category, the Length field uses variable-length encoding to indicate the byte length, and the Value field stores the actual data. The encapsulation order is as follows: nonce, cipher_x, tag_x, and target data identifier DSID_x, with a CRC-32 checksum appended at the end. After encapsulation, the encrypted packet Pkg_x is obtained.

[0086] The encryption engine combines {key index idx_RID_x, DSID_x, generation timestamp ts_x, SHA-256(tag_x)} into log entries and calls the AppendEntry interface of the log management module to write them to the block-based log file. Each log entry constructs a singly linked list using the hash value of the previous entry, forming an immutable time chain.

[0087] The communication management module reuses the TLS 1.3 tunnel established during access session establishment, uses the session key KSess_x to perform secondary transmission encryption on Pkg_x, and calculates the HMAC-SHA-256 message digest. Pkg_x, along with the HM AC, is sent to the requesting client carrying the role identifier. The entire transmission process relies on two-way certificate authentication and forward secure key exchange to ensure confidentiality and integrity.

[0088] For example, in a specific example process, after the "Operations Engineer" with the role identifier RID_OP completes the encrypted load statistics task, the compute node generates the target data Record_OP. The node submits a re-encryption request to the encryption engine, with parameters including Record_OP and DSID_OP.

[0089] The encryption engine calls TRNG from HSM to obtain a 96-bit random vector nonce_OP.

[0090] The encryption engine performs AES-256-GCM encryption with the role keys K_RID_OP and nonce_OP as input to obtain cipher_OP and tag_OP.

[0091] The engine encapsulates nonce_OP, cipher_OP, tag_OP, and DSID_OP in sequence according to the predefined TLV format, and appends a CRC-32 checksum to the end to form a ciphertext packet Pkg_OP.

[0092] The engine calculates SHA-256(tag_OP), which, together with idx_RID_OP and ts_OP, forms a log entry and is written to the chained log through the AppendEntry interface; the log management module returns EntryID_OP to confirm that the entry has been written to disk.

[0093] The communication management module obtains Pkg_OP and calls TLS_Send(KSess_OP, Pkg_OP), automatically appending an HMAC-SHA-256 digest internally, and then sends it to the requester through the existing TLS tunnel. The requester uses K_RID_OP and nonce_OP to decrypt cipher_OP and verify tag_OP and HMAC. If the verification passes, Record_OP is restored.

[0094] After receiving the ACK from the peer, the communication management module sends an Erase_KeySet command to the encryption engine. The encryption engine executes the MemZero command to clear K_RID_OP, nonce_OP and temporary buffers, and reports "Erase-OK" in the security audit channel.

[0095] Through the above implementation process, the platform achieves role-key-driven re-encryption and secure transmission. One-time random vectors avoid replay analysis, TLV encapsulation and chained logs provide traceable evidence, and bidirectional encrypted channels and session reuse improve transmission efficiency without reducing security levels, thereby ensuring that target data is only visible to legitimate roles and remains encrypted throughout the entire process.

[0096] In some embodiments, the re-encrypted target data is provided to the requester carrying a role identifier to enable the requester to access the power data, including:

[0097] The communication management module receives data retrieval instructions carrying role identifiers within an established secure session.

[0098] Provided the session is valid, the encrypted packet is forwarded from the computing node to the requesting terminal;

[0099] The log management module records the transmission timestamp, role identifier, and key index of the encrypted packet to complete the registration of the re-encrypted data delivery process.

[0100] Specifically, this embodiment will explain in detail the data delivery step of "providing the re-encrypted target data to the requester carrying the role identifier". First, the key technical features involved in this step and their implementation methods will be explained, and then a complete process example will be given.

[0101] First, the communication management module completes a two-way TLS handshake and saves the session key KSess during the role login phase. During the session lifetime, the module periodically sends TLS heartbeat frames and monitors HMAC consistency. If the verification fails, it forcibly disconnects and requires re-authentication to ensure that the data delivery phase is still under encrypted protection.

[0102] In some examples, the data retrieval command uses a JSON structure with fields including CmdType, DSID, RID, Token, and ReqTime. The communication management module first verifies that CmdType is "FETCH_CIPHER", and then calls the user management module to verify whether the Token and RID match and are within their validity period. Only after successful verification will the encrypted packet be forwarded to prevent unauthorized terminals from forging commands.

[0103] The compute nodes and the communication management module communicate via an internal gRPC stream, supporting backpressure control. When network jitter occurs or the client window size is adjusted, the communication management module uses a rate shaper to adjust the transmission rate in real time according to the current bandwidth, achieving smooth forwarding.

[0104] Furthermore, the log management module writes {EntryID, idx_RID, DSID, ts_send, ts_ack, sha256(Pkg)} to each delivery event, and calculates the next EntryHash from the previous EntryHash to ensure that the logs are tamper-proof.

[0105] Upon receiving the package, the requesting terminal must send back "DELIVER_OK" within 5 seconds. After receiving the confirmation, the communication management module sends a "KeyUseComplete" signal to the encryption engine, which immediately clears the temporary key cache associated with this delivery.

[0106] For example, in a specific example process, the operations engineer with the role of RID_OP has already obtained the re-encrypted ciphertext package Pkg_OP in the aforementioned steps and is waiting to download it.

[0107] The requesting terminal sends a data retrieval command to the communication management module through the established TLS tunnel: {"CmdTy pe":"FETCH_CIPHER","DSID":"RIDOP-T_meter","RID":"RID_OP","Token":"Token_OP","ReqTime":"20250522T164000Z"}.

[0108] The communication management module verifies that Token_OP and RID_OP match and are still valid. After confirming that the session heartbeat is normal, it writes the data retrieval instruction to the internal message queue.

[0109] The operator scheduling module queries the cache and locates Pkg_OP stored in compute node NODE_A. The compute node pushes Pkg_OP to the input buffer of the communication management module via gRPC stream.

[0110] The communication management module invokes the rate shaper to split the Pkg_OP into 20KB segments based on the current downlink bandwidth of 1.2MB / s. Each segment is accompanied by an incrementing sequence number and an HMAC value before being sent via a TLS tunnel. The requesting terminal verifies the HMAC segment by segment and reassembles the encrypted packet.

[0111] Once the last segment has been received and the CRC check is correct, the requesting terminal immediately sends "DELIVER_OK" back to the communication management module.

[0112] The communication management module records ts_ack and calls the log management module to append the log: EntryID:2475,idx_RID:idxRIDOP,DSID:RIDOP-T_meter,ts_send:20250522T164006Z,ts_ack:20250522T164018Z,sha256(Pkg_OP):…

[0113] The communication management module sends a "KeyUseComplete" command to the encryption engine. The encryption engine executes the MemZero command to clear K_RID_OP and related random vector caches, and returns "KEY_ERASED".

[0114] Upon receiving the "KEY_ERASED" event, the log management module appends a key to erase the log, forming...

[0115] To complete the delivery loop.

[0116] Through the above embodiments, the platform can securely and efficiently deliver re-encrypted target data to the legitimate requester without exposing plaintext. By leveraging chained logs and key lifecycle linkage, the platform ensures that the entire delivery process is traceable, auditable, and complies with the principle of least plaintext.

[0117] The following are embodiments of the apparatus described in this application, which can be used to execute the embodiments of the method described in this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the method described in this application.

[0118] Figure 2This is a schematic diagram of the structure of a power data access control device with a multi-layered encryption strategy provided in an embodiment of this application. Figure 2 As shown, the power data access control device with this multi-layered encryption strategy includes:

[0119] Module 201 is established to create a platform root key, a role key derived from a role identifier, and a homomorphic encryption public-private key pair bound to sensitive fields in the encryption engine, and to map the keys to the corresponding power data fields.

[0120] Encryption module 202 is used to perform the first layer of encryption on the power data block to be stored using the platform root key, perform the second layer of encryption on the set of fields belonging to the access level of the corresponding role using the role key, and perform the third layer of encryption on the sensitive fields using the homomorphic encryption public key.

[0121] Assembly module 203 is used to receive power data access requests carrying role identifiers and complete authentication, and assemble a data key set containing role keys and homomorphic encryption private keys when authentication is successful;

[0122] Distribution module 204 is used to distribute a set of data keys to computing nodes, enabling computing nodes to perform decryption or encrypted calculations on encrypted power data to obtain target data;

[0123] The re-encryption module 205 is used to re-encrypt the target data using the role key and provide the re-encrypted target data to the requester carrying the role identifier so that the requester can complete the access to the power data.

[0124] In some embodiments, Figure 2 The establishment module 201 calls a random number generator in the hardware security module to generate a platform root key and register the root key index; it uses a preset key derivation function to generate a corresponding role key with the platform root key and role identifier as input and registers the role key index; it calls a homomorphic encryption parameter generation algorithm to generate a homomorphic encryption public-private key pair for the power data field marked as a sensitive field and registers the homomorphic key index; it records the mapping relationship between the power data field identifier and the root key index, role key index and homomorphic key index in the metadata storage table to complete the mapping of power data fields to multi-layer keys.

[0125] In some embodiments, Figure 2Before writing the data, the encryption module 202 divides the power data to be stored into fragments according to a preset block size, and calls a symmetric encryption algorithm in the encryption engine to encrypt each data block with the platform root key to obtain the first layer of ciphertext blocks. According to the field-role mapping relationship, it retrieves the set of fields belonging to the target role's access level within the first layer of ciphertext blocks, and calls an encryption algorithm in the encryption engine to encrypt the field set with the corresponding role key to generate the second layer of ciphertext fields. For the field values ​​marked as sensitive fields, it calls the encryption function in the homomorphic encryption algorithm to encrypt the sensitive fields with the homomorphic encryption public key to generate the third layer of homomorphic ciphertext fields. The first layer of ciphertext blocks, the second layer of ciphertext fields, and the third layer of homomorphic ciphertext fields are combined and submitted to the data management module to complete the storage.

[0126] In some embodiments, Figure 2 Assembly module 203 receives power data access requests containing role identifiers in a two-way authentication secure channel through the communication management module; verifies the role identifiers by calling the authentication process in the user management module, and generates session credentials after successful verification; retrieves the role key index based on the role identifier and loads the corresponding role key in the encryption engine, and retrieves and loads the corresponding homomorphic encryption private key based on the sensitive field identifier to be accessed; encapsulates the role key and homomorphic encryption private key into a data key set, and outputs the data key set to the operator scheduling module after associating it with the session credentials.

[0127] In some embodiments, Figure 2 The distribution module 204 distributes the data key set to the target computing node through the communication management module in the established secure session. Under the scheduling instructions of the operator scheduling module, the computing node verifies its own identity based on the received session credentials and loads the data key set into the trusted execution environment. When the field to be processed corresponds to the role key encryption, the symmetric or asymmetric decryption algorithm in the encryption engine is called to decrypt the corresponding field with the role key. When the field to be processed corresponds to the homomorphic encrypted ciphertext, the homomorphic operation interface is called to complete the calculation of the corresponding field in the encrypted state. The results of each field obtained after decryption or encrypted calculation are merged to form the target data, and the data key set is cleared from the trusted execution environment after the calculation is completed.

[0128] In some embodiments, Figure 2 The re-encryption module 205 generates a one-time random number as an encryption vector in the encryption engine; calls a symmetric encryption algorithm to perform encryption operations on the target data based on the role key and the encryption vector to obtain re-encrypted ciphertext; encapsulates the re-encrypted ciphertext, the encryption vector, and the target data identifier into a ciphertext packet, and writes it to the log management module to register the key index and timestamp; and sends the ciphertext packet to the requester carrying the role identifier in the original session channel through the communication management module.

[0129] In some embodiments, Figure 2 The re-encryption module 205 receives a data retrieval instruction carrying a role identifier in an established secure session through the communication management module; provided the session is valid, it forwards the ciphertext packet from the computing node to the requesting terminal; and records the transmission timestamp, role identifier, and key index of the ciphertext packet in the log management module to complete the registration of the re-encrypted data delivery process.

[0130] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0131] Figure 3 This is a schematic diagram of the structure of the electronic device 3 provided in an embodiment of this application. Figure 3 As shown, the electronic device 3 of this embodiment includes a processor 301, a memory 302, and a computer program 303 stored in the memory 302 and executable on the processor 301. When the processor 301 executes the computer program 303, it implements the steps in the various method embodiments described above. Alternatively, when the processor 301 executes the computer program 303, it implements the functions of each module / unit in the various device embodiments described above.

[0132] For example, computer program 303 may be divided into one or more modules / units, which are stored in memory 302 and executed by processor 301 to complete this application. The one or more modules / units may be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of computer program 303 in electronic device 3.

[0133] Electronic device 3 can be a desktop computer, laptop, handheld computer, cloud server, or other electronic device. Electronic device 3 may include, but is not limited to, processor 301 and memory 302. Those skilled in the art will understand that... Figure 3 This is merely an example of electronic device 3 and does not constitute a limitation on electronic device 3. It may include more or fewer components than shown, or combine certain components, or different components. For example, electronic device may also include input / output devices, network access devices, buses, etc.

[0134] Processor 301 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.

[0135] The memory 302 can be an internal storage unit of the electronic device 3, such as a hard disk or RAM. The memory 302 can also be an external storage device of the electronic device 3, such as a plug-in hard disk, Smart Media Card (SMC), Secure Digital (SD) card, or Flash Card. Furthermore, the memory 302 can include both internal and external storage units of the electronic device 3. The memory 302 is used to store computer programs and other programs and data required by the electronic device. The memory 302 can also be used to temporarily store data that has been output or will be output.

[0136] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0137] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

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

[0139] In the embodiments provided in this application, it should be understood that the disclosed apparatus / computer devices and methods can be implemented in other ways. For example, the apparatus / computer device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. Multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces, and the indirect coupling or communication connection of apparatus or units may be electrical, mechanical, or other forms.

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

[0141] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0142] If integrated modules / units are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments 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 may include computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. Computer-readable media may include: any entity or device capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc.

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

Claims

1. A method for power data access control with multi-level encryption strategy, characterized in that, include: In the encryption engine, a platform root key, a role key derived from the role identifier, and a homomorphic encryption public-private key pair bound to sensitive fields are established, and the keys are mapped to the corresponding power data fields. The platform root key is used to perform the first layer of encryption on the power data block to be stored, the role key is used to perform the second layer of encryption on the set of fields belonging to the corresponding role access level, and the homomorphic encryption public key is used to perform the third layer of encryption on the sensitive fields. Receive power data access requests carrying role identifiers and complete authentication; assemble a data key set containing the role key and homomorphic encryption private key when authentication is successful. The data key set is distributed to computing nodes, enabling the computing nodes to perform decryption or encrypted computation on the encrypted power data to obtain the target data; The target data is re-encrypted using the role key, and the re-encrypted target data is provided to the requester carrying the role identifier so that the requester can complete the access to the power data; The step of distributing the data key set to computing nodes, enabling the computing nodes to perform decryption or encrypted computation on the encrypted power data to obtain the target data, includes: The data key set is distributed to the target computing node through the communication management module in the established secure session; Under the scheduling instructions of the operator scheduling module, the computing node verifies its own identity based on the received session credentials and loads the data key set into the trusted execution environment; When the role key corresponding to the field to be processed is encrypted, the symmetric or asymmetric decryption algorithm in the encryption engine is called to decrypt the corresponding field with the role key; When the field to be processed corresponds to homomorphic encrypted ciphertext, the homomorphic operation interface is called to complete the calculation of the corresponding field in encrypted state; The results of each field obtained after decryption and encrypted calculation are merged to form the target data, and the data key set is cleared from the trusted execution environment after the calculation is completed.

2. The method of claim 1, wherein, The process of establishing a platform root key, a role key derived from a role identifier, and a homomorphic encryption public-private key pair bound to sensitive fields in the encryption engine, and mapping the keys to the corresponding power data fields, includes: The hardware security module calls a random number generator to generate the platform root key and registers the root key index. Using a preset key derivation function, the corresponding role key is generated with the platform root key and role identifier as input, and the role key index is registered. For the power data field marked as a sensitive field, the homomorphic encryption parameter generation algorithm is invoked to generate a homomorphic encryption public-private key pair and register the homomorphic key index; The mapping relationship between the power data field identifier and the root key index, role key index and homomorphic key index is recorded in the metadata storage table to complete the mapping of power data fields to multi-level keys.

3. The method of claim 1, wherein, The process of performing a first layer of encryption on the power data block to be stored using the platform root key, performing a second layer of encryption on the set of fields belonging to the corresponding role access level using the role key, and performing a third layer of encryption on the sensitive fields using the homomorphic encryption public key includes: Before the data is written, the power data to be stored is divided into segments according to a preset block size, and a symmetric encryption algorithm is called in the encryption engine to encrypt each data block with the platform root key to obtain the first layer of ciphertext blocks. Based on the field-role mapping relationship, the set of fields belonging to the target role's access level is retrieved within the first-layer ciphertext block, and the encryption algorithm is called in the encryption engine to encrypt the set of fields with the corresponding role key to generate the second-layer ciphertext field. For the field value marked as a sensitive field, the encryption function in the homomorphic encryption algorithm is called to encrypt the sensitive field with the homomorphic encryption public key, generating a third-layer homomorphic ciphertext field; The first-layer ciphertext block, the second-layer ciphertext field, and the third-layer homomorphic ciphertext field are combined and submitted to the data management module for storage.

4. The method of claim 1, wherein, The process of receiving a power data access request carrying a role identifier and completing authentication, and assembling a data key set containing the role key and a homomorphic encryption private key upon successful authentication, includes: The communication management module receives power data access requests containing role identifiers in a two-way authenticated secure channel. The user management module invokes the authentication process to verify the role identifier, and generates session credentials after successful verification. In the encryption engine, the role key index is retrieved based on the role identifier and the corresponding role key is loaded. At the same time, the corresponding homomorphic encryption private key is retrieved and loaded based on the sensitive field identifier to be accessed. The role key and the homomorphic encryption private key are encapsulated into a data key set, and the data key set is associated with the session credentials and then output to the operator scheduling module.

5. The method according to claim 1, characterized in that, The step of re-encrypting the target data using the role key includes: Generate a one-time random number as the encryption vector in the encryption engine; A symmetric encryption algorithm is invoked to perform encryption operations on the target data based on the role key and the encryption vector, resulting in re-encrypted ciphertext. The re-encrypted ciphertext, the encryption vector, and the target data identifier are encapsulated into a ciphertext package, and written into the log management module to register the key index and timestamp; The encrypted packet is sent to the requester carrying the role identifier in the original session channel via the communication management module.

6. The method according to claim 5, characterized in that, The step of providing the re-encrypted target data to the requester carrying the role identifier, so that the requester can complete access to the power data, includes: The communication management module receives data retrieval instructions carrying the role identifier in an established secure session; Provided the session is valid, the encrypted packet is forwarded from the computing node to the requesting terminal; The transmission timestamp, role identifier, and key index of the encrypted packet are recorded in the log management module to complete the registration of the re-encrypted data delivery process.

7. A power data access control device with a multi-level encryption strategy, characterized in that, include: The module is used to establish a platform root key, a role key derived from a role identifier, and a homomorphic encryption public-private key pair bound to sensitive fields in the encryption engine, and to map the keys to the corresponding power data fields. The encryption module is used to perform a first layer of encryption on the power data block to be stored using the platform root key, to perform a second layer of encryption on the set of fields belonging to the corresponding role access level using the role key, and to perform a third layer of encryption on the sensitive fields using the homomorphic encryption public key. An assembly module is used to receive power data access requests carrying role identifiers and complete authentication, and assemble a data key set containing the role key and homomorphic encryption private key when the authentication is successful; The distribution module is used to distribute the data key set to computing nodes, enabling the computing nodes to perform decryption or encrypted calculations on the encrypted power data to obtain the target data. The re-encryption module is used to re-encrypt the target data using the role key, and provide the re-encrypted target data to the requester carrying the role identifier so that the requester can complete the access to the power data; Specifically, the distribution module is used to distribute the data key set to the target computing node through the communication management module in the established secure session; under the scheduling instructions of the operator scheduling module, the computing node verifies its own identity based on the received session credentials and loads the data key set into the trusted execution environment; when the field to be processed corresponds to the role key encryption, the symmetric or asymmetric decryption algorithm in the encryption engine is called to decrypt the corresponding field with the role key; when the field to be processed corresponds to the homomorphic encrypted ciphertext, the homomorphic operation interface is called to complete the calculation of the corresponding field in the encrypted state; the results of each field obtained after decryption and encrypted calculation are merged to form the target data, and the data key set is cleared from the trusted execution environment after the calculation is completed.

8. An electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method as described in any one of claims 1 to 6.

9. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method as described in any one of claims 1 to 6.

Images