Power data access control method and device based on multi-level encryption strategy

Abstract

The invention provides a power data access control method and device based on a multi-level encryption strategy. The method comprises the following steps: establishing a platform root key, a role key derived based on a role identifier and a homomorphic encryption public and private key pair bound with a sensitive field in an encryption engine, and mapping the keys to a corresponding power data field; performing first-layer encryption on the to-be-stored power data block by using the platform root key, performing second-layer encryption on the field set belonging to the corresponding role access level by using the role key, and performing third-layer encryption on the sensitive field by using the homomorphic encryption public key; distributing the data key set to a computing node, and enabling the computing node to execute decryption or secret state calculation on the encrypted power data to obtain target data; and re-encrypting the target data by using the role key, and providing the re-encrypted target data to the requester carrying the role identifier. According to the method and the device, data security access of fine-grained permission isolation and online secret state calculation can be considered.

Description

TECHNICAL FIELD

[0001] The application relates to the technical field of data encryption, in particular to a power data access control method and device based on a multi-level encryption strategy. BACKGROUND

[0002] With the deepening of the digital transformation of the power grid, dispatching, power generation, transmission and distribution, and power market business systems continue to generate large-scale heterogeneous data. Power data not only has important significance for ensuring the safe operation and accurate dispatching of the power grid, but also contains considerable commercial value in load forecasting, equipment health management, and energy trading scenarios. The documents issued by regulatory departments at all levels clearly propose the security circulation principle of "original data not out of the domain, data available but not visible", which puts forward higher compliance requirements for power enterprises in the process of data sharing and trading.

[0003] With the formation of the data element market, power grid enterprises need to establish controllable and trustworthy data circulation channels between multiple departments within the group and external research institutions and equipment manufacturers. Different subjects have obvious differences in data granularity and sensitivity requirements, and it is necessary to not only ensure consistent key business indicators, but also strictly limit access beyond authority. Therefore, the platform urgently needs a multi-level encryption access control mechanism that combines role permissions, field sensitivity, and cryptographic computing capabilities to support collaborative analysis and modeling without exposing plaintext.

[0004] Existing technologies generally adopt single or few-layer encryption methods: first, database disk-level whole-database encryption only provides static protection and cannot meet fine-grained authorization; second, attribute-based access control (ABAC) usually relies on a single key or access token, and the key needs to be reissued in its entirety when the role changes, resulting in high maintenance costs; third, column-level or row-level transparent encryption can hide sensitive content by field, but decryption is still required when cross-domain statistics or machine learning are needed, and it cannot be coordinated with homomorphic encryption, differential privacy, and other cryptographic computing technologies. In addition, most solutions do not link role-derived keys with dynamic usage measurement, making it difficult to control or trace data usage in real time.

[0005] The existing technical solutions at least have the following defects: first, there is a lack of support for homomorphic encryption and other cryptographic operations, and once data is encrypted, online computing capabilities are lost; second, role or field authorization is not clearly bound to the encryption level, and role adjustments require large-scale re-encryption, affecting system usability; third, multiple independent key systems coexist, and cannot be uniformly derived and rotated, which can easily lead to key leakage risks; finally, the existing mechanism focuses on static authorization and lacks dynamic fuse capabilities linked to usage measurement and call thresholds, making it difficult to meet the contract billing needs of data trading scenarios. SUMMARY

[0006] Therefore, the application provides a power data access control method and device based on a multi-level encryption strategy to solve the problem that the prior art cannot balance fine-grained permission isolation and data access control in a ciphertext state.

[0007] In a first aspect, the application provides a power data access control method based on a multi-level encryption strategy, which comprises: establishing a platform root key, a role key derived based on a role identifier, and a homomorphic encryption public-private key pair bound to a sensitive field in an encryption engine, and mapping the keys to corresponding power data fields; performing first-level encryption on a power data block to be stored by using the platform root key, performing second-level encryption on a field set belonging to a corresponding role access level by using the role key, and performing third-level encryption on a sensitive field by using a homomorphic encryption public key; receiving a power data access request carrying a role identifier and completing identity verification, assembling a data key set containing the role key and the homomorphic encryption private key when the identity verification is passed; distributing the 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 by using the role key, and providing the re-encrypted target data to a requester carrying the role identifier, so that the requester completes the access to the power data.

[0008] In a second aspect, the application provides a power data access control device based on a multi-level encryption strategy, which comprises: an establishment module configured to establish a platform root key, a role key derived based on a role identifier, and a homomorphic encryption public-private key pair bound to a sensitive field in an encryption engine, and map the keys to corresponding power data fields; an encryption module configured to perform first-level encryption on a power data block to be stored by using the platform root key, perform second-level encryption on a field set belonging to a corresponding role access level by using the role key, and perform third-level encryption on a sensitive field by using a homomorphic encryption public key; an assembly module configured to receive a power data access request carrying a role identifier and complete identity verification, and assemble a data key set containing the role key and the homomorphic encryption private key when the identity verification is passed; a distribution module configured to distribute the 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; and a re-encryption module configured to re-encrypt the target data by using the role key, and provide the re-encrypted target data to a requester carrying the role identifier, so that the requester completes the access to the power data.

[0009] In a third aspect, the application provides an electronic device, which comprises a memory, a processor, and a computer program stored in the memory and executable on the processor, and the processor implements the steps of the above method when executing the computer program.

[0010] In a fourth aspect, the present application provides a computer readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the above method.

[0011] The above at least one technical solution adopted by the embodiments of the present application can achieve the following beneficial effects:

[0012] By 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 the encryption engine, and mapping the keys to corresponding power data fields, a first layer of encryption is performed on the to-be-stored power data block using the platform root key, a second layer of encryption is performed on the field set belonging to the corresponding role access level using the role key, and a third layer of encryption is performed on the sensitive field using the homomorphic encryption public key; a power data access request carrying a role identifier is received and identity verification is completed, and when the identity verification is passed, a data key set containing the role key and the homomorphic encryption private key is assembled; the data key set is distributed to the computing node, so that the computing node performs decryption or ciphertext computation on the encrypted power data to obtain 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 completes the access to the power data. The present application can balance the fine-grained permission isolation and the online ciphertext computation data security access. BRIEF DESCRIPTION OF DRAWINGS

[0013] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the embodiments or prior art description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0014] Figure 1 is a flowchart of the power data access control method provided by the multi-level encryption strategy of the embodiments of the present application;

[0015] Figure 2 is a structural schematic diagram of the power data access control device provided by the multi-level encryption strategy of the embodiments of the present application;

[0016] Figure 3 is a structural schematic diagram of the electronic device provided by the embodiments of the present application. DETAILED DESCRIPTION

[0017] In the following description, for purposes of explanation and not limitation, specific details are set forth such as particular architectures, technologies, techniques, etc. in order to provide a thorough understanding of the embodiments of the present application. However, it will be apparent to those skilled in the art that the present application can be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known systems, devices, circuits, and methods are omitted so as not to obscure the description of the present application with unnecessary detail.

[0018] The prior art generally uses database whole-database encryption, column-level transparent encryption or attribute-based access control (ABAC) to protect power data. However, whole-database encryption can only provide static protection, column-level encryption still needs to be decrypted when collaborative analysis is performed, and the ABAC scheme needs to reissue keys on a large scale once the role or field permission is adjusted, and it is difficult to balance fine-grained isolation, operation performance and key management burden. As a result: the permission granularity is coarse, the ciphertext calculation is limited, and the key rotation is complex.

[0019] Based on the above defects, the technical problem faced by the present application is that the prior art cannot simultaneously meet the data access control requirements of fine-grained permission isolation and ciphertext calculation. To solve this problem, the present application proposes a multi-level encryption strategy for power data access control method, and the core technical scheme of the present application includes:

[0020] A hierarchical key system of a platform root key-role-derived key-sensitive field homomorphic key pair is established in the encryption engine, and each key index is mapped to the corresponding data field;

[0021] The root key is used to encrypt the data block in the first layer, the role key is used to encrypt the role field set in the second layer, and the homomorphic public key is used to encrypt the sensitive field in the third layer, forming a ciphertext storage that can be authorized in stages;

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

[0023] The computing node returns the result encrypted again with the role key, realizing end-to-end ciphertext circulation.

[0024] The above technical scheme enables the platform to realize role-level and field-level bidirectional isolation without exposing plaintext, and supports online ciphertext operation such as homomorphic calculation, further simplifying the key derivation and rotation process. The technical effect achieved is: balancing fine-grained permission isolation and online ciphertext calculation for data security access, while reducing the complexity of key management, meeting the compliance requirements of "original data not out of domain, data available and invisible" for power data.

[0025] The content of the technical scheme of the present application will be described in detail below in combination with the drawings and specific embodiments.

[0026] Figure 1 is a flowchart of a multi-level encryption strategy power data access control method provided by an embodiment of the present application. As shown in the figure, the multi-level encryption strategy power data access control method can specifically include the following steps. Figure 1

[0027] S101, establishing a platform root key, a role key derived based on a role identifier, and a homomorphic encryption public-private key pair bound to a sensitive field in an encryption engine, and mapping the keys to corresponding power data fields;

[0028] S102, performing first-level encryption on a power data block to be stored using the platform root key, performing second-level encryption on a field set belonging to a corresponding role access level using the role key, and performing third-level encryption on a sensitive field using the homomorphic encryption public key;

[0029] S103, receiving a power data access request carrying a role identifier and completing identity verification, and assembling a data key set containing the role key and the homomorphic encryption private key when the identity verification is passed;

[0030] S104, distributing the 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;

[0031] S105, re-encrypting the target data using the role key, and providing the re-encrypted target data to a requestor carrying the role identifier, so that the requestor completes access to the power data.

[0032] In some embodiments, establishing a platform root key, a role key derived based on a role identifier, and a homomorphic encryption public-private key pair bound to a sensitive field in an encryption engine, and mapping the keys to corresponding power data fields, includes:

[0033] Calling a random number generator in a hardware security module to generate a platform root key and registering a root key index;

[0034] Generating a corresponding role key using a preset key derivation function with the platform root key and the role identifier as inputs and registering a role key index;

[0035] Calling a homomorphic encryption parameter generation algorithm for power data fields marked as sensitive fields to generate a homomorphic encryption public-private key pair and registering a homomorphic key index;

[0036] Recording a mapping relationship between power data field identifiers and root key indexes, role key indexes, and homomorphic key indexes in a metadata storage table to complete mapping of power data fields to multi-level keys.

[0037] ​Specifically, in the present embodiment, the power data security circulation platform is deployed with an encryption engine, a hardware security module (HSM), a metadata management component, and a user management component. The encryption engine is responsible for unified calling of cryptographic primitives and maintaining a multi-layer key system; the HSM provides high-entropy random numbers and key-level protection; the metadata management component is responsible for recording field-key mapping; and the user management component saves role identifiers and provides derivation parameters to the encryption engine.

[0038] First, a platform root key K0 is generated by a true random number generator of the HSM. After generation, K0 is stored in plaintext in the HSM in a never-out-of-module manner, and an external system only obtains a root key index idx0 returned by the HSM, which is written into a root key record item of a key repository for subsequent derivation and auditing.

[0039] Second, after obtaining a role identifier RID returned by the user management component, the system calls a key derivation function KDF built in the encryption engine. The KDF takes K0 and RID as inputs, generates a role key K_RID through HMAC-SHA256 iteration operation, and returns a role key index idx_RID. K_RID is imported into an erasable memory area of the encryption engine in ciphertext form, and a role key record item is added in the key repository, which only saves idx_RID and the bound RID.

[0040] Third, 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 a secure parameter (for example, a polynomial order of 4096, a modulus bit length of 218, etc.). After generation, the homomorphic key index idx_HE_i is immediately registered, and sk_i is sealed and stored by the HSM, and only pk_i and idx_HE_i are disclosed to the computing node.

[0041] Subsequently, the metadata management component writes four pieces of bound information in the field table for each data field: a field identifier FID, a root key index idx0, a role key index idx_RID, and a homomorphic key index idx_HE_i. When the field does not belong to a specific role or is not a sensitive field, the corresponding index item is empty, indicating that this layer is not effective. The field table triggers an event to notify the encryption engine to cache the latest mapping after forming or updating the mapping.

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

[0043] Through the implementation mode of the above embodiment, the generation, derivation, registration, and field mapping process of the multi-layer key are completely disclosed, which provides a clear key index and calling path for subsequent three-layer encryption, ciphertext calculation, and result re-encryption links, and ensures that the platform can realize fine-grained data access control in the dual dimensions of role level and field level.

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

[0045] Before data writing, the power data to be stored is fragmented 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 a first layer of ciphertext blocks;

[0046] According to the field and role mapping relationship, the field set belonging to the target role access level is searched in the first layer of ciphertext blocks, and an encryption algorithm is called in the encryption engine to encrypt the field set with the corresponding role key to generate a second layer of ciphertext fields;

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

[0048] 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 for storage.

[0049] Specifically, the embodiment is directed to the three-layer encryption link in the power data writing process. Firstly, the key technical features and implementation modes involved in the link are explained: firstly, the block fragmentation mechanism is introduced to ensure that large-capacity power data is fragmented into fixed-size blocks, which facilitates unified block-level encryption by the platform root key; secondly, a field-role mapping index is constructed, and the platform can quickly locate the fields belonging to a specific role access level in the pure ciphertext state without decrypting the entire block; thirdly, column-level homomorphic encryption technology is used to directly generate a ciphertext expression for the field values marked as sensitive, allowing subsequent aggregation or training in a ciphertext environment. The above three features are uniformly arranged by the encryption engine, which sequentially performs root key encryption, role key encryption, and homomorphic key encryption operations, and is stored persistently by the data management module after completion.

[0050] In the actual implementation process, the platform first receives the power data set to be written. Before writing, the encryption engine divides the data stream into continuous blocks with a size of 16 MB according to the system-level parameters. The encryption engine calls the built-in AES-256-GCM algorithm to perform encryption on each data block with the platform root key K0, generating the first layer of ciphertext blocks cipher_blk. This operation is completed in a pipeline manner inside 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 section belonging to the target role in the metadata associated with cipher_blk according to the field-role mapping index. For example, the role "operation and maintenance engineer" corresponds to a field set containing meter_id and substation_code. The encryption engine extracts the binary segments of these fields in cipher_blk, calls the AES-256-GCM algorithm, and re-encrypts them with the role key K_RID, outputting the second layer of ciphertext fields cipher_role. The cipher_role ciphertext is replaced back to the corresponding position of cipher_blk in place, and the encryption identifier is recorded for read and write parsing.

[0052] For the avg_load field marked as high-sensitivity, the system configures a homomorphic public key pk_load for it in advance. 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 modular operation on the field value with pk_load, directly generating the third layer of homomorphic ciphertext fields cipher_HE. cipher_HE no longer participates in role key encryption, but is appended to the end of cipher_blk in the form of an independent column, and its starting offset and length are simultaneously registered in the metadata.

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

[0054] Through the implementation mode of the above embodiment, the embodiment completes the three-layer encryption processing of the block level, the role level and the sensitive field level of the power data in the data writing stage, ensures that the key rotation or permission change of any subsequent layer can be independently effective, and lays the key and storage foundation for online encrypted computing.

[0055] In some embodiments, a power data access request carrying a role identifier is received and identity verification is completed, and when the identity verification is passed, a data key set containing a role key and a homomorphic encryption private key is assembled, including:

[0056] The power data access request containing the role identifier is received in the two-way authentication secure channel through the communication management module;

[0057] The identity verification process is called in the user management module to verify the role identifier, and a session credential is generated after the verification is passed;

[0058] In the encryption engine, the role key index is retrieved according to the role identifier and the corresponding role key is loaded, and the corresponding homomorphic encryption private key is retrieved and loaded according to the sensitive field identifier to be accessed;

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

[0060] Specifically, the embodiment describes the key issuance link in the power data access process. Firstly, the key technical features and implementation modes of this link are explained: firstly, the platform establishes a trusted communication basis between the client and the center node through a two-way authentication secure channel, ensuring that the role identifier and the subsequent key material are not tampered with by the intermediate person; secondly, the identity verification process of the user management module is decoupled from the role key repository, and the authentication result is passed to the encryption engine through the session credential, realizing the layered isolation of identity authentication and key calling; thirdly, the data key set packaging mechanism binds the role key and the homomorphic private key to the same session context, so as to accurately control the key life cycle on the operator scheduling module side.

[0061] In actual operation, the access client first initiates a TLS 1.3 handshake to the communication management module, and fills in the role identifier RID OP in the ClientHello extension field of the handshake. After the communication management module verifies the peer certificate, a bidirectional encryption channel is established. Subsequently, the client submits a power data access request through the channel, which contains the target data set identifier T meter and the field list {meter_id, avg_load}.

[0062] Further, the user management module calls the internal OAuth2 authentication process after receiving the request, retrieves the account state and permission policy corresponding to RID OP. After identity verification, the user management module generates a session credential Token OP with a validity period of two hours, and passes Token OP to the encryption engine together with RID OP.

[0063] Further, the encryption engine queries the key repository according to RID OP, locates the role key index idx_RID_OP and loads the role key K_RID_OP into the controlled memory area. At the same time, the field list is parsed, and it is found 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 unseal 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 as the data key set KeySet_OP.

[0064] Further, the encryption engine writes KeySet_OP and Token_OP into the session context to form a pair of 〈Token_OP, KeySet_OP〉, and pushes it to the operator scheduling module through the internal message bus. The operator scheduling module holds a read-only handle to KeySet_OP, which can trigger key erasure immediately after the task is completed, ensuring that the residence time of key material in RAM is controlled.

[0065] Through the implementation mode of the above embodiment, the embodiment discloses the complete implementation details from secure channel establishment, role identity authentication to data key set encapsulation and distribution, and details the cooperative relationship and operation sequence of key technical features, providing secure and reliable key support for subsequent ciphertext calculation tasks.

[0066] In some embodiments, the data key set is distributed to the computing node, so that the computing node performs decryption or homomorphic calculation on the encrypted power data to obtain the target data, comprising:

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

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

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

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

[0071] The decrypted or ciphertext calculation results of each field are combined to form target data, and the data key set is cleared from the trusted execution environment after the calculation is completed.

[0072] Specifically, the present embodiment explains the process of the data key set distribution and use. The key technical features of the process include: first, secure session key distribution, which ensures that the key material is transmitted only in an encrypted channel; second, trusted execution environment loading, which ensures that the role key and the homomorphic private key are used in isolated memory and controlled by the hardware instruction set; third, decryption-ciphertext operation mixed pipeline, which uses symmetric or asymmetric decryption for role key encrypted fields and directly calls homomorphic operators for homomorphic ciphertext fields to complete the operation; fourth, the keys are cleared immediately after the task is completed, and the trusted memory is synchronized and erased by the zeroization instruction and key handle revocation mechanism to prevent subsequent processes from stealing. The specific implementation steps are as follows:

[0073] First, the communication management module has established a TLS tunnel with the target computing node in advance. After receiving the pair of, the operator scheduling module pushes to the node through the TLS tunnel, while attaching for identity verification. The encryption engine on the node side parses in the local security processor, and after comparing with the signature public key of the center node to complete the verification, loads into the Intel SGX-based secure area.

[0074] Further, during the task execution period, the node first locates the fields meter_id and substation_code encrypted by the role key. The encryption engine calls the AES256GCM decryption interface to decrypt with the role key KRIDOP and the random vector stored in the ciphertext header, and restores the plaintext field. Then the node processes the sensitive field avg_load, which is homomorphic ciphertext. The encryption engine directly calls the EvalSum and EvalScale operators of the CKKS library to complete the section summation and scaling operation in the ciphertext state, generating the homomorphic result cipherSum. CipherSum can participate in subsequent merging without decryption.

[0075] Further, after all field calculations are completed, the node writes the plaintext meter_id, substation_code and homomorphic result cipherSum to the output buffer to form the target data RecordOP. After the operator scheduling module confirms that RecordOP has been written to the disk snapshot, it calls the encryption engine to trigger key erasure. The engine executes the MemsetZero and EEXIT combined instructions to forcibly clear KRIDOP and skload in the secure area, and destroys the KeySetOP handle. Finally, the communication management module sends a "key set has been cleared" status code to the center node to ensure the complete closed loop of the audit chain.

[0076] Through the above embodiments, the platform realizes the full-link closed loop of key issuance, identity verification, trusted loading, hybrid decryption-ciphertext computation and immediate key erasure, ensures that the role key and homomorphic private key exist only temporarily in the trusted environment, and enables the computing node to securely output the target data after permission isolation and ciphertext operation processing.

[0077] In some embodiments, the role key is used to re-encrypt the target data, including:

[0078] A one-time random number is generated in the encryption engine as an encryption vector;

[0079] A symmetric encryption algorithm is called to perform encryption operations on the target data based on the role key and the encryption vector, to obtain re-encrypted ciphertext;

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

[0081] The ciphertext package is sent to the requestor carrying the role identifier in the original session channel through the communication management module.

[0082] Specifically, the present embodiment discloses in detail the technical scheme of "re-encrypting the target data using the role key", first explains the technical features and implementation methods contained in the scheme, and then describes it in combination with a typical flow example.

[0083] First, to avoid ciphertext duplication of different data packages under the same role key, the encryption engine calls the true random number generator TRNG integrated in the hardware security module HSM before each re-encryption to generate a random byte sequence nonce with a length of 96 bits. The TRNG meets the randomness detection requirements of GB / T18336 and NIST SP800-90B, ensuring the quality of the entropy source. The nonce is only valid within the current session and is written to the isolated register of the encryption engine after generation.

[0084] In some examples, the encryption algorithm is selected as the AES-256-GCM mode, and the key material is the role key KRID_x bound in the user login stage. The encryption engine calls the AEAD_Encrypt interface with {KRID_x, nonce, target data Record_x} as input, and outputs the re-encrypted ciphertext cipher_x and the authentication tag tag_x, where the length of tag_x is 128 bits, used for integrity verification. KRID_x remains in the controlled buffer area of the encryption engine after encryption is completed until the ciphertext package is successfully sent and triggers erasure.

[0085] To facilitate downstream parsing and auditing, the platform defines a unified TLV (Type-Length-Value) packaging 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 packaging order is nonce, cipher_x, tag_x, and target data identifier DSID_x, followed by a CRC-32 check code. After packaging, the ciphertext package 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 a log entry, and calls the AppendEntry interface of the log management module to write to the block log file. Each log entry forms a one-way linked list through the hash value of the previous entry, forming an unalterable time chain.

[0087] The communication management module reuses the TLS1.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 is sent to the requester client along with the HMAC, along with 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, when the "operation and maintenance engineer" with a role identifier of RID_OP completes the task of statistical load in encrypted form, the computing node generates target data Record_OP. The node submits a re-encryption request to the encryption engine, including Record_OP and DSID_OP.

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

[0090] The encryption engine performs AES-256-GCM encryption with the role key 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, DSID_OP in sequence according to a predefined TLV format, and appends a CRC-32 check at the end to form a ciphertext package Pkg_OP.

[0092] The engine calculates SHA-256(tag_OP), and forms a log entry together with idx_RID_OP and ts_OP, and writes the log entry to the chain log through the AppendEntry interface; the log management module returns EntryID_OP to confirm the disk landing.

[0093] The communication management module obtains Pkg_OP and calls TLS_Send(KSess_OP, Pkg_OP), automatically appends an HMAC-SHA-256 digest inside, and then sends it to the requester through the existing TLS tunnel. The requester decrypts cipher_OP using K_RID_OP and nonce_OP, and verifies tag_OP and HMAC. If the verification is passed, Record_OP is restored.

[0094] After receiving the ACK from the opposite end, the communication management module sends an Erase_KeySet instruction to the encryption engine. The encryption engine executes the MemZero instruction to clear K_RID_OP, nonce_OP, and temporary cache, and reports "Erase-OK" on the security audit channel.

[0095] Through the above implementation process, the platform realizes role key-driven re-encryption and secure transmission. The one-time random vector avoids replay analysis, TLV encapsulation and chain log provide traceable evidence, and the bidirectional encryption channel and session reuse improve transmission efficiency without reducing security level, thereby ensuring that the target data is only visible to the legitimate role and is in an encrypted state throughout.

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

[0097] Through the communication management module, receive the data retrieval instruction carrying the role identifier in the established secure session;

[0098] Under the premise that the session is valid, forward the ciphertext package from the computing node to the requester terminal;

[0099] Record the transmission timestamp, role identifier, and key index of the ciphertext package in the log management module to complete the registration of the re-encrypted data delivery process.

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

[0101] First, the communication management module has completed the two-way TLS handshake in the role login stage and saved the session key KSess; during the session lifetime, the module sends a TLS heartbeat frame regularly and monitors the HMAC consistency. If the verification fails, it will be forced to disconnect and require re-authentication, ensuring that the data delivery stage is still under encryption protection.

[0102] In some examples, the data retrieval instruction adopts a JSON structure, and the fields include 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 Token and RID match and are within the valid period. Only if the verification is successful, the ciphertext package will be forwarded, avoiding illegal terminal forgery instructions.

[0103] The internal gRPC stream is used between the computing node and the communication management module, supporting back pressure control. When the network jitter or client window size is adjusted, the communication management module uses a rate shaper to adjust the sending rate in real time according to the current bandwidth, achieving smooth forwarding.

[0104] Further, the log management module writes {EntryID, idx_RID, DSID, ts_send, ts_ack, sha256(Pkg)} for each delivery event, and calculates the next EntryHash based on the previous EntryHash, ensuring that the log is tamper-proof.

[0105] The requestor terminal needs to return "DELIVER_OK" within 5 seconds after receiving the Pkg. After receiving the receipt, the communication management module sends a "KeyUseComplete" signal to the encryption engine, and the encryption engine immediately clears the temporary key cache associated with this delivery.

[0106] For example, in one specific example flow, the operation and maintenance engineer with the role of RID_OP has obtained the re-encrypted ciphertext package Pkg_OP in the previous steps and is waiting for download.

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

[0108] The communication management module checks that the Token_OP matches the RID_OP and is still within the valid period, confirms that the session heartbeat is normal, and writes the data retrieval instruction to the internal message queue.

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

[0110] The communication management module calls the rate shaper, splits the Pkg_OP into 20 KB fragments according to the current downlink bandwidth of 1.2 MB / s, and sends each fragment through a TLS tunnel after attaching an incremental serial number and an HMAC value. The requester terminal verifies the HMAC for each fragment and reassembles the ciphertext package.

[0111] When the last fragment is received and the CRC check is correct, the requester terminal immediately returns "DELIVER_OK" to the communication management module.

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

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

[0114] The log management module receives the "KEY_ERASED" event and appends another key erasure log, which is

[0115] The complete delivery closed loop is formed.

[0116] Through the above embodiments, the platform safely and efficiently delivers the re-encrypted target data to the legitimate requester without exposing the plaintext, and ensures that the entire delivery process is traceable, auditable, and complies with the minimum plaintext principle by means of chain logs and key life cycle linkage.

[0117] The following is an apparatus embodiment of the present application, which can be used to execute the method embodiments of the present application. For details not disclosed in the apparatus embodiments of the present application, please refer to the method embodiments of the present application.

[0118] Figure 2Fig. 1 is a structural schematic diagram of a power data access control device with a multi-level encryption strategy provided by an embodiment of the present application. As shown in Fig. 1, the power data access control device with the multi-level encryption strategy comprises: Figure 2

[0119] The establishing module 201 is configured to establish 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 map the keys to corresponding power data fields.

[0120] The encryption module 202 is configured to perform first-level encryption on a power data block to be stored by using the platform root key, perform second-level encryption on a field set belonging to a corresponding role access level by using the role key, and perform third-level encryption on a sensitive field by using the homomorphic encryption public key.

[0121] The assembling module 203 is configured to receive a power data access request carrying a role identifier and complete identity verification, and assemble a data key set containing the role key and the homomorphic encryption private key when the identity verification is passed.

[0122] The distribution module 204 is configured to distribute the 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.

[0123] The re-encryption module 205 is configured to re-encrypt the target data by using the role key, and provide the re-encrypted target data to a requester carrying the role identifier, so that the requester completes access to the power data.

[0124] In some embodiments, Figure 2 The establishing module 201 of the power data access control device with the multi-level encryption strategy is configured to call a random number generator in a hardware security module to generate a platform root key and register a root key index; use a preset key derivation function to generate a corresponding role key by taking the platform root key and a role identifier as inputs and register a role key index; call a homomorphic encryption parameter generation algorithm for power data fields marked as sensitive fields to generate a homomorphic encryption public-private key pair and register a homomorphic key index; and record a mapping relationship between power data field identifiers and the root key index, the role key index, and the homomorphic key index in a metadata storage table, so as to complete mapping of the power data fields to the multi-level keys.

[0125] In some embodiments, Figure 2 ​The encryption module 202 of the power data management system divides the power data to be stored into fragments according to a preset block size before data writing, and calls a symmetric encryption algorithm in an encryption engine to encrypt each data block with a platform root key, to obtain a first layer of ciphertext blocks; according to a field-role mapping relationship, a field set belonging to a target role access level is searched in the first layer of ciphertext blocks, and an encryption algorithm is called in the encryption engine to encrypt the field set with a corresponding role key, to generate a second layer of ciphertext fields; for a field value marked as a sensitive field, an encryption function in a homomorphic encryption algorithm is called to encrypt the sensitive field with a homomorphic encryption public key, to generate a 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 for storage.

[0126] In some embodiments, Figure 2 The assembly module 203 receives a power data access request containing a role identifier in a two-way authentication secure channel through the communication management module; calls an identity verification process in the user management module to verify the role identifier, and generates a session credential after verification; searches and loads a corresponding role key according to the role identifier in the encryption engine, and searches and loads a corresponding homomorphic encryption private key according to the sensitive field identifier to be accessed; encapsulates the role key and the homomorphic encryption private key into a data key set, and outputs the data key set to the operator scheduling module after associating the data key set with the session credential.

[0127] In some embodiments, Figure 2 The distribution module 204 distributes the data key set to the target computing node in the established secure session through the communication management module; under the scheduling instruction of the operator scheduling module, the computing node verifies its own identity based on the received session credential and loads the data key set into a trusted execution environment; when the role key is encrypted, the corresponding field is decrypted with the role key by calling the symmetric or asymmetric decryption algorithm in the encryption engine; when the corresponding field is encrypted with the homomorphic encryption ciphertext, the homomorphic operation interface is called to complete the calculation of the corresponding field in the ciphertext state; the field results obtained by decryption or ciphertext calculation are combined to form 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 an encryption operation 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 package, and writes it into the log management module to register the key index and the timestamp; sends the ciphertext package to the requestor 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 the data fetching instruction carrying the role identifier in the established secure session through the communication management module; forwards the ciphertext package from the computing node to the requester terminal on the premise that the session is valid; records the transmission timestamp of the ciphertext package, the role identifier and the key index in the log management module to complete the registration of the re-encryption data delivery process.

[0130] It should be understood that the size of the serial number of each step in the above embodiments does not mean the order of execution, and the execution order of each process should be determined according to its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0131] Figure 3 is a structural schematic diagram of the electronic device 3 provided by the embodiments of the present application. As shown in Figure 3 The electronic device 3 of the embodiment includes a processor 301, a memory 302, and a computer program 303 stored in the memory 302 and executable on the processor 301. The processor 301 implements the steps in each of the above method embodiments when executing the computer program 303. Alternatively, the processor 301 implements the functions of each module / unit in each of the above device embodiments when executing the computer program 303.

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

[0133] The electronic device 3 can be a desktop computer, a notebook computer, a palm computer, a cloud server and the like. The electronic device 3 can include but is not limited to the processor 301 and the memory 302. Those skilled in the art can understand that Figure 3 The electronic device 3 is only an example of the electronic device 3 and does not constitute a limitation on the electronic device 3, and can include more or fewer components than those shown, or combine certain components, or different components, for example, the electronic device can also include an input / output device, a network access device, a bus, etc.

[0134] The processor 301 can be a central processing unit (CPU), or other general purpose processors, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or the like. The general purpose processor can be a microprocessor, or the processor can be any conventional processor, etc.

[0135] The memory 302 can be an internal storage unit of the electronic device 3, for example, a hard disk or a memory of the electronic device 3. The memory 302 can also be an external storage device of the electronic device 3, for example, a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, or the like equipped on the electronic device 3. Further, the memory 302 can include both the internal storage unit and the external storage device 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 can clearly understand that, for the convenience and brevity of description, only the division of the above functional units and modules is exemplified, and in actual application, the above functions can be completed by different functional units and modules according to needs, that is, the internal structure of the device is divided into different functional units or modules to complete all or part of the functions described above. Each functional unit and module in the embodiment can be integrated in one processing unit, or each unit can exist physically, or two or more units can be integrated in one unit. The integrated unit can be realized in the form of hardware or in the form of a software functional unit. In addition, the specific names of each functional unit and module are only for easy distinction, and do not limit the protection scope of the present application. The specific working process of the units and modules in the above system can refer to the corresponding process in the foregoing method embodiments, which will not be described here.

[0137] In the above embodiments, the description of each embodiment has its own emphasis, and the parts not described or recorded in detail in a certain embodiment can be referred to the relevant description of other embodiments.

[0138] Those skilled in the art can understand that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be realized by electronic hardware or a combination of computer software and electronic hardware. Whether the functions are realized 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 the present application.

[0139] In the embodiments provided in the present application, it should be understood that the disclosed apparatus / computer device and method can be implemented in other ways. For example, the apparatus / computer device embodiments described above are merely schematic, for example, the division of the modules or units is only a logical function division, and there can be another division manner in actual implementation, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the units shown or discussed can be indirect coupling or communication connection through some interface, device or unit, and can be electrical, mechanical or other forms.

[0140] The units described as separate components can or can not be physically separate, and the components shown as units can or can not be physical units, that is, they can be located in one place, or can be distributed on multiple network units. Part or all of the units can be selected according to actual needs to achieve the purpose of the embodiments.

[0141] In addition, each functional unit in each embodiment of the present application can be integrated into a processing unit, or each unit can exist physically independently, or two or more units can be integrated into one unit. The integrated unit can be realized in the form of hardware or in the form of a software functional unit.

[0142] The integrated modules / units, if implemented in the form of software functional units and sold or used as independent products, can be stored in a computer readable storage medium. Based on such understanding, all or part of the processes in the above-mentioned embodiment methods can also be completed by a computer program instructing related hardware, and the computer program can be stored in a computer readable storage medium. The computer program can be executed by a processor to implement the steps of the above-mentioned various method embodiments. The computer program can include computer program code, which can be in the form of source code, object code, executable files, or some intermediate forms. The computer readable medium can include any entity or device capable of carrying the computer program code, recording medium, U disk, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal, and software distribution medium, etc.

[0143] The above embodiments are only used to illustrate the technical solutions of the present application, but not limit them; although the technical solutions of the present application are described in detail with reference to the foregoing embodiments, those skilled in the art should understand that the technical solutions recorded in the foregoing embodiments can be modified, or some technical features can be replaced by equivalents; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present application, and should be included in the protection scope of the present application.

Claims

1. A method for power data access control with multi-level encryption strategy, characterized in that, Comprise: Establishing a platform root key, a role key derived based on a role identifier, and a homomorphic encryption public-private key pair bound to a sensitive field in an encryption engine, and mapping the keys to corresponding power data fields; Performing first layer encryption on a to-be-stored power data block 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 the sensitive field using the homomorphic encryption public key; Receiving a power data access request carrying a role identifier and completing identity verification, assembling a data key set containing the role key and the homomorphic encryption private key when the identity verification is passed; Distributing the 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 the requestor carrying the role identifier, so that the requestor completes access to the power data.

2. The method of claim 1, wherein, The establishment of the platform root key, the role key derived based on the role identifier, and the homomorphic encryption public-private key pair bound to the sensitive field in the encryption engine, and the mapping of the keys to the corresponding power data fields, comprise: Calling a random number generator in a hardware security module to generate a platform root key and registering a root key index; Using a preset key derivation function to generate a corresponding role key using the platform root key and the role identifier as input and registering a role key index; Calling a homomorphic encryption parameter generation algorithm for power data fields marked as sensitive fields to generate a homomorphic encryption public-private key pair and registering a homomorphic key index; Recording 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 the power data field to the multi-layer key.

3. The method of claim 1, wherein, The first layer encryption on the to-be-stored power data block using the platform root key, the second layer encryption on the field set belonging to the corresponding role access level using the role key, and the third layer encryption on the sensitive field using the homomorphic encryption public key, comprise: Before data writing, the to-be-stored power data is fragmented according to a preset block size, and a symmetric encryption algorithm is called in the encryption engine to encrypt each data block using the platform root key to obtain a first layer ciphertext block; According to the field and role mapping relationship, the field set belonging to the target role access level is searched in the first layer ciphertext block, and an encryption algorithm is called in the encryption engine to encrypt the field set using the corresponding role key to generate a second layer ciphertext field; For field values marked as sensitive fields, an encryption function in the homomorphic encryption algorithm is called to encrypt the sensitive field using the homomorphic encryption public key to generate 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 receiving of the power data access request carrying the role identifier and the completion of the identity verification, the assembling of the data key set containing the role key and the homomorphic encryption private key when the identity verification is passed, comprise: Receiving, by a communication management module, a power data access request containing a role identifier in a bidirectional authentication secure channel; Verifying, in a user management module, the role identifier by invoking an identity verification process, and generating a session credential after verification; Retrieving, in an encryption engine, a role key index according to the role identifier and loading a corresponding role key, and retrieving and loading a corresponding homomorphic encryption private key according to a sensitive field identifier to be accessed; Encapsulating the role key and the homomorphic encryption private key as a data key set, and outputting the data key set to an operator scheduling module after associating the data key set with the session credential.

5. The method of claim 1, wherein, The data key set is distributed to the computing node, and the computing node performs decryption or ciphertext computation on the encrypted power data to obtain target data, including: The data key set is sent to the target computing node in the established secure session through the communication management module; Under the scheduling instruction of the operator scheduling module, the computing node verifies its identity based on the received session credential and loads the data key set into a trusted execution environment; When the role key 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 to-be-processed field corresponds to homomorphic encryption ciphertext, the homomorphic operation interface is called to complete the calculation of the corresponding field in the ciphertext state; The field results obtained by decryption or ciphertext computation are combined to form target data, and the data key set is cleared from the trusted execution environment after the computation is completed.

6. The method of claim 1, wherein, The target data is re-encrypted using the role key, including: A one-time random number is generated as an encryption vector in the encryption engine; A symmetric encryption algorithm is called to perform encryption operation on the target data based on the role key and the encryption vector to obtain re-encrypted ciphertext; The re-encrypted ciphertext, the encryption vector and the target data identifier are encapsulated as a ciphertext package, and are written into a log management module to register the key index and the timestamp; The ciphertext package is sent to the requestor carrying the role identifier in the original session channel through the communication management module.

7. The method of claim 6, wherein, The re-encrypted target data is provided to the requestor carrying the role identifier, so that the requestor completes the access to the power data, including: A data retrieval instruction carrying the role identifier is received in the established secure session through the communication management module; The ciphertext package is forwarded from the computing node to the requestor terminal under the premise that the session is valid; The transmission timestamp of the ciphertext package, the role identifier and the key index are recorded in the log management module to complete the registration of the re-encrypted data delivery process.

8. A multi-tiered encryption policy power data access control device, characterized by, The establishment module is used to establish, in an encryption engine, a platform root key, a role key derived based on a role identifier, and a homomorphic encryption public-private key pair bound to a sensitive field, and to map the keys to corresponding power data fields; The encryption module is used to perform first layer encryption on a power data block to be stored using the platform root key, perform second layer encryption on a field set belonging to a corresponding role access level using the role key, and perform third layer encryption on the sensitive field using the homomorphic encryption public key; ​ An assembling module is configured to receive a power data access request carrying a role identifier and complete identity verification, and assemble a data key set containing the role key and a homomorphic encryption private key when the identity verification is passed; A distribution module is configured to distribute the data key set to a computing node, so that the computing node performs decryption or homomorphic computation on encrypted power data to obtain target data; A re-encryption module is configured to re-encrypt the target data using the role key, and provide the re-encrypted target data to a requester carrying a role identifier, so that the requester completes access to the power data.

9. An electronic device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, The processor executes the computer program to implement the steps of the method of any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, the computer program comprising instructions that, when executed by a computer, cause the computer to perform the method of any one of claims 1 to 9. The computer program is executed by the processor to implement the steps of the method of any one of claims 1 to 7.

Images