A power cloud data security access method and system

Abstract

The application belongs to the technical field of network communication security, and discloses a power cloud data security access method and system, which comprises the following steps: a client constructs and sends an access request packet containing a protocol version number, a checksum, basic information and a digital certificate; after receiving the request packet, a server carries out checksum verification and protocol verification; a security access chain is generated by extracting the main body of the request packet, and time window verification, data access permission verification and access frequency verification are carried out; after verification, digital certificate authentication is carried out, and supplementary authentication is carried out if necessary; after successful authentication, the server generates a dynamic encryption key to encrypt the data and sends the data to the client, and the client generates a corresponding decryption key to decrypt the data. Through the standardized request format, dynamic key generation and multiple verification mechanisms, the application ensures the security and reliability of data access, effectively prevents unauthorized access and unauthorized operation, and provides reliable protection for the security access of power cloud data.

Description

Technical Field

[0001] The present invention relates to the field of network communication security technology, and more specifically, to a method and system for securely accessing power cloud data. Background Art

[0002] With the deepening of power system informatization, the power cloud platform has become an important infrastructure for power data storage, processing, and sharing. In this power cloud environment, ensuring the security and controllability of data access has become a key issue in ensuring the stable operation of the power system.

[0003] However, existing power cloud data access solutions suffer from numerous security deficiencies. First, traditional access control mechanisms often rely on static username and password authentication, making them incapable of addressing security threats such as identity forgery and replay attacks. Second, data access rights management lacks granular control, making it impossible to implement differentiated security policies based on data sensitivity and user roles. Furthermore, the lack of effective encryption and integrity verification during data transmission makes data leaks and tampering more likely.

[0004] Current power cloud platforms typically use simple authentication and authorization mechanisms when processing data access requests, failing to fully consider security factors such as access timeliness, frequency control, and dynamic authentication. This approach not only increases data security risks but also fails to meet the power industry's stringent requirements for data access security, potentially posing a threat to the safe and stable operation of power systems. Summary of the Invention

[0005] In order to overcome the data security risks in the prior art, the present invention proposes a method and system for secure access to power cloud data to solve the above problems.

[0006] The present invention provides the following technical solutions:

[0007] A method for securely accessing electric power cloud data, comprising:

[0008] S1. The client constructs and sends an access request packet for power cloud data, wherein the access request packet includes a request packet header and a request packet body;

[0009] S2. The server receives the access request packet and verifies the access request packet according to the header of the request packet;

[0010] S3. Obtain the request verification result, extract the request package body for the access request package that passes the request verification, and generate a security access chain based on the extracted request package body;

[0011] S4. Perform access verification based on the generated security access chain, including time window verification, data access permission verification, and access frequency verification;

[0012] S5. Obtain access verification results. If data access permission verification, access frequency verification, and time window verification are all passed, identity authentication is performed based on the security access chain.

[0013] S6. Obtain the identity authentication result. After the identity authentication is passed, the server generates an encryption key based on the security access chain, encrypts the requested data, and sends it to the client. The client generates the corresponding decryption key to decrypt the received data.

[0014] Preferably, the request packet header includes a data transmission protocol version number and a checksum; the request packet body includes basic information and a digital certificate; the basic information includes a request type, a request target, a request span, a timestamp, and requester information.

[0015] Preferably, the request verification includes:

[0016] Calculate the checksum of the access request packet and compare the calculated checksum with the checksum provided in the request packet header; if they are the same, perform protocol verification; if they are different, determine the request verification result as failed;

[0017] The protocol verification includes: obtaining a data transmission protocol version number and comparing it with a list of data transmission protocol version numbers supported by the server;

[0018] If the same data transmission protocol version number is not found, the request verification result is judged as failed;

[0019] If the same data transmission protocol version number is found, the transmission protocol rule corresponding to the data transmission protocol version number is extracted, and the request packet is checked to see if it complies with the transmission protocol rule;

[0020] If it meets the requirements, the request verification result is judged as passed; if it does not meet the requirements, the request verification result is judged as failed.

[0021] Preferably, the step of generating a security access chain based on the extracted request packet body includes:

[0022] Get the basic information in the request package body;

[0023] Use the request type, request target, request span, timestamp, and requester information in the basic information to form the first chain;

[0024] According to the requester information and the request target, the request frequency of the requester to the request target is obtained from the server side and recorded as the server frequency;

[0025] Obtain metadata for the request target, including type, permission number, window time, allowed frequency, and authentication identifier; wherein the permission number corresponds to a permission table, which includes authorized users and corresponding span permissions; and the authentication identifier indicates whether supplementary authentication is required.

[0026] The second chain is formed using the server frequency and metadata of the requested data;

[0027] The first chain and the second chain are combined to form a secure access chain.

[0028] Preferably, the time window verification includes obtaining a timestamp and a window time in the security access chain, and determining whether the timestamp is within the window time;

[0029] If not, the time window verification fails; if so, the time difference is obtained by subtracting the current time from the timestamp to determine whether the time difference is within the preset time difference range;

[0030] If yes, the time window verification passes; if no, the time window verification fails;

[0031] The data access permission verification includes: obtaining the permission number and requester information in the security access chain, obtaining the permission table according to the permission number, and querying whether the requester is an authorized user in the permission table;

[0032] If not, the data access permission verification fails; if so, the corresponding span permission is obtained to determine whether the requested span in the security access chain is within the span permission;

[0033] If yes, the data access permission verification is passed; if no, the data access permission verification is failed;

[0034] The access frequency verification includes: obtaining the server frequency and the allowed frequency in the security access chain, and judging whether the request frequency is not greater than the allowed frequency. If so, the access frequency verification passes; otherwise, the access frequency verification fails.

[0035] Preferably, the step of performing identity authentication according to the secure access chain includes:

[0036] Obtain digital certificates and verify them;

[0037] When the digital certificate verification fails, it is determined that the identity authentication fails;

[0038] When the digital certificate is verified, the authentication identifier of the secure access chain is obtained;

[0039] If the authentication flag is no, the identity authentication is determined to be successful;

[0040] If the certification mark is yes, then supplementary certification is performed;

[0041] If the supplementary authentication passes, the identity authentication is determined to be passed; otherwise, the identity authentication fails.

[0042] Preferably, the step of supplementary authentication includes:

[0043] Obtain the public key from the digital certificate, generate a random challenge code on the server side, and combine the challenge code and generation time into the information to be signed;

[0044] The information to be signed is sent to the client, which uses the private key to digitally sign the information to be signed and returns the signature result to the server;

[0045] The server uses the public key to decrypt the signature result and determines whether the decrypted signature result is consistent with the information to be signed. At the same time, it determines whether the difference between the generation time in the decrypted signature result and the current time is within a preset range;

[0046] When both of the above judgment results are yes, the supplementary authentication is determined to be passed; otherwise, the supplementary authentication is determined to be failed.

[0047] Preferably, the step of generating the encryption key includes: obtaining the request type, timestamp, requester information and server frequency in the security access chain; generating the encryption key using a key generation algorithm according to the request type, timestamp, requester information and server frequency;

[0048] The steps for generating the decryption key include: obtaining the request type, timestamp, requester information and request target in the access request package, obtaining the request frequency of the requester for the request target recorded by the client and recording it as the client frequency; using the same key generation algorithm to generate the decryption key based on the request type, timestamp, requester information and client frequency in the access request package.

[0049] The present invention also provides a power cloud data security access system for implementing a power cloud data security access method, comprising:

[0050] A request packet construction module, configured for the client to construct and send an access request packet for power cloud data, wherein the access request packet includes a request packet header and a request packet body;

[0051] The request verification module is used for receiving the access request packet at the server side and performing request verification on the access request packet according to the request packet header;

[0052] The security chain generation module is used to obtain the request verification result, extract the request package body for the access request package that passes the request verification, and generate a security access chain based on the extracted request package body;

[0053] Access verification module, used to perform access verification based on the generated security access chain, including data access permission verification, access frequency verification, and time window verification;

[0054] The identity authentication module is used to obtain access verification results. When data access permission verification, access frequency verification, and time window verification are all passed, identity authentication is performed according to the security access chain.

[0055] The data security transmission module is used to obtain the identity authentication result. After the identity authentication is passed, the server generates an encryption key based on the security access chain, encrypts the requested data and sends it to the client. The client generates the corresponding decryption key to decrypt the received data.

[0056] The present invention provides a method and system for secure access to power cloud data, which has the following beneficial effects:

[0057] By designing a standardized access request format that includes a request packet header and a request packet body, combined with checksum verification and protocol verification mechanisms, the integrity and accuracy of data transmission can be effectively ensured. At the same time, the setting of the protocol version number provides good scalability for subsequent protocol upgrades, making the system more adaptable and maintainable. The present invention designs a triple verification mechanism consisting of time window verification, data access permission verification, and access frequency verification. By precisely controlling the timeliness, scope of permission, and access frequency of data access, the security of data access is significantly improved. In particular, the introduction of the permission table realizes refined permission management based on user identity and data characteristics, effectively preventing unauthorized access and unauthorized operations. In addition, the present invention constructs a complete data access security protection system through a dual identity authentication mechanism based on digital certificate verification and supplementary authentication, combined with an encryption and decryption scheme for dynamic key generation. This mechanism can not only effectively prevent identity forgery and replay attacks, but also ensure the security of the data transmission process through dynamic key generation, providing reliable protection for secure access to power cloud data. BRIEF DESCRIPTION OF THE DRAWINGS

[0058] Figure 1 A schematic diagram of a flow chart of a method for securely accessing power cloud data according to the present invention;

[0059] Figure 2 This is a module diagram of a power cloud data security access system of the present invention. DETAILED DESCRIPTION

[0060] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention. Example 1

[0061] See also Figure 1 In this embodiment, a method for securely accessing power cloud data includes:

[0062] S1. The client constructs and sends an access request packet for power cloud data, wherein the access request packet includes a request packet header and a request packet body;

[0063] The request packet header includes the data transmission protocol version number and checksum; the request packet body includes basic information and a digital certificate; the basic information includes request type, request target, request span, timestamp and requester information.

[0064] In this embodiment, the client first constructs an access request packet, consisting of a header and a body, to initiate a data access request to the power cloud data platform. The header contains two key fields: the data transmission protocol version number and a checksum. The data transmission protocol version number identifies the currently used protocol version, ensuring compatibility between the client and server communication protocols. The checksum verifies the integrity and accuracy of the data transmission. This checksum can be calculated by converting the contents of the access request packet into corresponding numerical values ​​using ASCII or Unicode code points and then adding them together.

[0065] You can also treat the string as a series of binary bits and then perform bitwise operations (such as XOR) to get the checksum.

[0066] The main body of the request package consists of two parts: basic information and a digital certificate. The basic information includes the following key fields: request type, which is used to describe the operation type of this request, such as data query, data writing, etc.; request target, which indicates the specific data object or resource that needs to be accessed; request span: describes the time range of the required data; timestamp: records the specific time when the request is initiated, which is used to control the timeliness of the request; requester information: contains the user identity information of the user who initiated the request, including user ID, department, and other information. The digital certificate ensures the legitimacy of the source of the request. After completing the construction of the request package, the client sends it to the power cloud data platform through a secure network channel. This standardized request package format design not only ensures the security of data access, but also improves the efficiency and reliability of data transmission. At the same time, by setting the version number, space is also reserved for subsequent protocol upgrades and optimizations.

[0067] S2. The server receives the access request packet and verifies the access request packet according to the header of the request packet;

[0068] The request verification includes:

[0069] Calculate the checksum of the access request packet and compare the calculated checksum with the checksum provided in the request packet header; if they are the same, perform protocol verification; if they are different, determine the request verification result as failed;

[0070] The protocol verification includes: obtaining a data transmission protocol version number and comparing it with a list of data transmission protocol version numbers supported by the server;

[0071] If the same data transmission protocol version number is not found, the request verification result is judged as failed;

[0072] If the same data transmission protocol version number is found, the transmission protocol rule corresponding to the data transmission protocol version number is extracted, and the request packet is checked to see if it complies with the transmission protocol rule;

[0073] If it meets the requirements, the request verification result is judged as passed; if it does not meet the requirements, the request verification result is judged as failed.

[0074] In this embodiment, after receiving the access request packet, the server first needs to perform strict request verification to ensure the security and reliability of data access. The request verification process mainly includes two steps: checksum verification and protocol verification.

[0075] For checksum verification, the server recalculates the checksum of the entire access request packet using the same algorithm as the client (such as MD5 or SHA-256). The calculated checksum is then compared with the checksum provided in the request packet header. Only if the two are identical will the protocol verification step proceed. If the checksums do not match, it indicates that the data may have been tampered with or damaged during transmission, and the request verification result will be immediately rejected.

[0076] During protocol verification, the server first obtains the data transmission protocol version number from the request packet header and compares it with a list of supported protocol versions. Servers typically maintain a list of supported protocol versions to ensure backward compatibility with multiple protocol versions. If the protocol version number in the request packet is not found in the supported list, it indicates that the client is using an unsupported protocol version, and verification will be directly failed.

[0077] If a matching protocol version number is found, the server further extracts the transport protocol rules corresponding to that version. These rules can be customized based on actual needs and typically include specific specifications such as data format requirements, required field checks, and field value range limits. The server then performs a comprehensive check of the request packet based on these rules, ensuring that its structure and content fully comply with the protocol specifications. Only request packets that pass all rule checks are considered validated; otherwise, they are considered failed.

[0078] This multi-level verification mechanism can effectively ensure the standardization of data access. At the same time, when the protocol needs to be updated, it is only necessary to add new protocol version support on the server side and formulate corresponding rules. It has strong scalability and maintainability.

[0079] S3. Obtain the request verification result, extract the request package body for the access request package that passes the request verification, and generate a security access chain based on the extracted request package body;

[0080] The step of generating a security access chain according to the extracted request packet body includes:

[0081] Get the basic information in the request package body;

[0082] Use the request type, request target, request span, timestamp, and requester information in the basic information to form the first chain;

[0083] According to the requester information and the request target, the request frequency of the requester to the request target is obtained from the server side and recorded as the server frequency;

[0084] Obtain metadata for the request target, including type, permission number, window time, allowed frequency, and authentication identifier; wherein the permission number corresponds to a permission table, which includes authorized users and corresponding span permissions; and the authentication identifier indicates whether supplementary authentication is required.

[0085] The second chain is formed using the server frequency and metadata of the requested data;

[0086] The first chain and the second chain are combined to form a secure access chain.

[0087] In this embodiment, for the access request packet that passes the request verification, the server needs to further process it to generate a secure access chain. The generation process of the secure access chain involves the construction and combination of two main chains.

[0088] First, the server extracts basic information from the request packet body, including the request type, request target, request span, timestamp, and requester information. This information is organized into the first chain according to a predetermined format to record the basic characteristics of this request.

[0089] Next, the server will query the user's historical access records to the target data based on the requester information and the request target, and calculate the server frequency. This frequency can be measured in time intervals such as days and hours, such as calculating the number of accesses in the last day, the number of accesses in the last hour, or the number of accesses in other time intervals. At the same time, the server will obtain metadata information of the request target. Metadata is usually set when the data is generated. It contains multiple attributes used to describe the data. In this embodiment, they are: type, which describes the nature and classification of the data; permission number, which is associated with the permission table and is used to determine the scope of access rights for different users; window time, which specifies the time window in which data is allowed to be accessed, such as access from 8:00 to 20:00; allowed frequency: the maximum number of accesses allowed to the data, which can be measured in time intervals such as days and hours; authentication identifier: indicates whether additional identity authentication is required. Usually, for more important data, this is indicated as yes.

[0090] The permissions table is a crucial configuration table that records users with access rights and their corresponding span permissions. Permissioned users can be identified by user ID or department. Span permissions refer to the time span within which a user can access current data, such as data within seven days. This allows precise control over the scope of a user's data access. The server organizes the acquired server frequency and metadata into a second chain.

[0091] Finally, the server combines the first and second chains to form a complete security access chain. This security access chain includes the basic characteristics of the request, the user's access behavior characteristics, and the security control requirements of the data, providing a decision basis for subsequent access control.

[0092] S4. Perform access verification based on the generated security access chain, including time window verification, data access permission verification, and access frequency verification;

[0093] The time window verification includes obtaining the timestamp and window time in the security access chain and determining whether the timestamp is within the window time;

[0094] If not, the time window verification fails; if so, the time difference is obtained by subtracting the current time from the timestamp to determine whether the time difference is within the preset time difference range;

[0095] If yes, the time window verification passes; if no, the time window verification fails;

[0096] The data access permission verification includes: obtaining the permission number and requester information in the security access chain, obtaining the permission table according to the permission number, and querying whether the requester is an authorized user in the permission table;

[0097] If not, the data access permission verification fails; if so, the corresponding span permission is obtained to determine whether the requested span in the security access chain is within the span permission;

[0098] If yes, the data access permission verification is passed; if no, the data access permission verification is failed;

[0099] The access frequency verification includes: obtaining the server frequency and the allowed frequency in the security access chain, and judging whether the request frequency is not greater than the allowed frequency. If so, the access frequency verification passes; otherwise, the access frequency verification fails.

[0100] In this embodiment, the server needs to perform triple verification on the generated security access chain: time window verification, data access permission verification, and access frequency verification. Only by passing these three verifications at the same time can the legitimacy and security of data access be ensured.

[0101] Time window verification primarily controls the timeliness of requests. First, the timestamp and window time are extracted from the security access chain to determine whether the timestamp is within the valid window time range. If it is not within the window time, the request is not allowed at that time, and verification is immediately deemed to have failed. If it is within the window time, the time difference between the current time and the timestamp is further calculated and compared with the preset time difference range. The preset time difference range can be set based on actual business needs, for example, 5 minutes or 10 minutes. Only when the time difference is within the preset range can the time window verification be considered passed, effectively preventing replay attacks and expired requests.

[0102] Data access permission verification primarily ensures that the requester has appropriate access rights. First, the permission number and requester information are retrieved from the security access chain. The corresponding permission table is then searched using the permission number. The permission table records all users with access rights and their corresponding span permissions. The verification process first checks whether the requester is in the permission table. If not, the user does not have any access rights, and verification is immediately deemed to have failed. If the requester is in the permission table, the corresponding span permissions are retrieved and compared with the requested span. Permission verification is considered successful only if the requested span is within the permitted span permissions. This multi-layered permission control mechanism precisely manages the access rights of different users to different data ranges.

[0103] Access frequency verification controls access frequency by comparing the server frequency with the permitted frequency. These two frequency values ​​are obtained from the secure access chain and compared. Frequency verification passes only if the server frequency does not exceed the permitted frequency. This mechanism effectively prevents excessive load and data leakage risks caused by frequent access.

[0104] This triple-verification mechanism forms a rigorous access control system: time window verification ensures the timeliness of requests; permission verification ensures that the accessor has appropriate permissions; and frequency verification prevents excessive access. By adjusting the parameters of each verification step, such as the time difference range, span permission, and allowed frequency, the strictness of data access can be flexibly controlled according to actual needs, ensuring data security while also balancing availability and flexibility.

[0105] S5. Obtain access verification results. If data access permission verification, access frequency verification, and time window verification are all passed, identity authentication is performed based on the security access chain.

[0106] The steps of performing identity authentication according to the security access chain include:

[0107] Obtain digital certificates and verify them;

[0108] When the digital certificate verification fails, it is determined that the identity authentication fails;

[0109] When the digital certificate is verified, the authentication identifier of the secure access chain is obtained;

[0110] If the authentication flag is no, the identity authentication is determined to be successful;

[0111] If the certification mark is yes, then supplementary certification is performed;

[0112] If the supplementary authentication passes, the identity authentication is determined to be passed; otherwise, the identity authentication fails.

[0113] The steps of the supplementary certification include:

[0114] Obtain the public key from the digital certificate, generate a random challenge code on the server side, and combine the challenge code and generation time into the information to be signed;

[0115] The information to be signed is sent to the client, which uses the private key to digitally sign the information to be signed and returns the signature result to the server;

[0116] The server uses the public key to decrypt the signature result and determines whether the decrypted signature result is consistent with the information to be signed. At the same time, it determines whether the difference between the generation time in the decrypted signature result and the current time is within a preset range;

[0117] When both of the above judgment results are yes, the supplementary authentication is determined to be passed; otherwise, the supplementary authentication is determined to be failed.

[0118] In this embodiment, after the request passes the time window verification, data access permission verification, and access frequency verification, identity authentication is performed to further ensure the security of data access. The identity authentication process includes two levels: basic digital certificate verification and optional supplementary authentication.

[0119] First, the digital certificate in the request body is retrieved and verified. Digital certificate verification typically includes certificate chain verification, certificate validity period check, and certificate revocation status query. If digital certificate verification fails, the identity authentication is directly considered a failure, and subsequent data access requests are denied.

[0120] When the digital certificate is verified, an authentication identifier is obtained from the secure access chain. The authentication identifier is used to indicate whether supplementary authentication is required. This mechanism allows different levels of security protection to be adopted for data of different importance. If the authentication identifier is negative, it means that the basic digital certificate verification is sufficient and the identity authentication is directly determined to be passed. If the authentication identifier is positive, a more stringent supplementary authentication is required. The specific process of supplementary authentication is as follows:

[0121] The server first extracts the user's public key from the digital certificate and generates a random challenge code. This challenge code is typically a random string of sufficient length to ensure its unpredictability. The server combines the challenge code with its generation time to form the message to be signed.

[0122] The server sends the information to be signed to the client. Upon receiving the information, the client digitally signs it using its private key. This process verifies that the client possesses the private key that matches the public key in the certificate, thereby proving its authenticity. The client returns the signature result to the server. Upon receiving the signature result, the server decrypts it using the public key it previously obtained and performs two key verifications: First, it verifies that the decrypted content is identical to the original information to be signed, ensuring the accuracy of the signing process; and second, it checks that the difference between the decrypted generation time and the current time is within a reasonable preset range (e.g., 30 seconds) to prevent delay attacks.

[0123] Only when both verifications pass is the supplementary authentication considered successful, and the entire authentication process is considered successful. This multi-layered authentication mechanism effectively prevents security threats such as identity forgery and replay attacks. Furthermore, by setting authentication identifiers, flexible authentication strategies can be adopted for data at different security levels, ensuring security while avoiding excessive authentication overhead.

[0124] S6. Obtain the identity authentication result. After the identity authentication is passed, the server generates an encryption key based on the security access chain, encrypts the requested data, and sends it to the client. The client generates the corresponding decryption key to decrypt the received data.

[0125] The steps of generating the encryption key include: obtaining a request type, a timestamp, requester information, and a server frequency in the security access chain; generating an encryption key using a key generation algorithm according to the request type, timestamp, requester information, and server frequency;

[0126] The steps for generating the decryption key include: obtaining the request type, requester information and request target in the access request package, obtaining the request frequency of the requester for the request target recorded by the client and recording it as the client frequency; using the same key generation algorithm to generate the decryption key based on the request type, timestamp, requester information and client frequency in the access request package.

[0127] In this embodiment, once the request passes identity authentication, the system enters the data transmission phase. To ensure data transmission security, the server and client employ a dynamic key-based encryption and decryption mechanism. This mechanism features dynamic key generation with each request, and the server and client can independently generate paired encryption and decryption keys.

[0128] The server-side encryption key generation process is as follows: Key information is extracted from the secure access chain, including the request type, timestamp, requester information, and server frequency. The server then uses this information as input parameters using a predefined key generation algorithm to generate the encryption key for this data transmission. This key generation algorithm can be implemented by concatenating the input parameters in a fixed order, computing the concatenated result using a secure hash function (such as SHA-256), and using the hash result as a seed to generate the final encryption key using a key derivation function (such as PBKDF2).

[0129] The client's decryption key generation process mirrors this process: it obtains relevant information locally, including the request type, timestamp, requester information, and client frequency (locally recorded frequency of access to the target). Using the exact same key generation algorithm as the server, this information is used as input parameters to generate the decryption key. Because the client and server use the same algorithm and corresponding parameters, they can generate matching keys.

[0130] This dynamic key generation mechanism has the following advantages: the key changes dynamically with the request. Even if the key of a certain communication is cracked, it will not affect the security of other communications. There is no need for explicit key exchange, which reduces the risk of interception. By using access frequency as one of the parameters, the key generation process is associated with the user's access behavior. If the local and server records are inconsistent, the correct decryption key cannot be generated, which increases security.

[0131] In this embodiment, the server encrypts the requested data using the generated encryption key, employing a symmetric encryption algorithm such as AES. The encrypted data is then sent to the client via a secure channel. Upon receiving the encrypted data, the client decrypts it using the generated decryption key, retrieving the original data. Example 2

[0132] See also Figure 2 The present invention provides a power cloud data security access system for implementing a power cloud data security access method, including:

[0133] A request packet construction module, configured for the client to construct and send an access request packet for power cloud data, wherein the access request packet includes a request packet header and a request packet body;

[0134] The request verification module is used for receiving the access request packet at the server side and performing request verification on the access request packet according to the request packet header;

[0135] The security chain generation module is used to obtain the request verification result, extract the request package body for the access request package that passes the request verification, and generate a security access chain based on the extracted request package body;

[0136] Access verification module, used to perform access verification based on the generated security access chain, including data access permission verification, access frequency verification, and time window verification;

[0137] The identity authentication module is used to obtain access verification results. When data access permission verification, access frequency verification, and time window verification are all passed, identity authentication is performed according to the security access chain.

[0138] The data security transmission module is used to obtain the identity authentication result. After the identity authentication is passed, the server generates an encryption key based on the security access chain, encrypts the requested data and sends it to the client. The client generates the corresponding decryption key to decrypt the received data.

[0139] In the several embodiments provided by the present invention, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of the units is only one type. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0140] The above description is only a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any technician familiar with this technical field can easily think of changes or replacements within the technical scope disclosed by the present invention, which should be covered by the scope of protection of the present invention.

[0141] Finally: The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. A method for secure access to power cloud data, characterized in that: include: S1. The client constructs and sends an access request packet for power cloud data, wherein the access request packet includes a request packet header and a request packet body; S2. The server receives the access request packet and verifies the access request packet according to the header of the request packet; S3. Obtain the request verification result, extract the request package body for the access request package that passes the request verification, and generate a security access chain based on the extracted request package body; The step of generating a security access chain according to the extracted request packet body includes: Get the basic information in the request package body; Use the request type, request target, request span, timestamp, and requester information in the basic information to form the first chain; According to the requester information and the request target, the request frequency of the requester to the request target is obtained from the server side and recorded as the server frequency; Obtain metadata for the request target, including type, permission number, window time, allowed frequency, and authentication identifier; wherein the permission number corresponds to a permission table, which includes authorized users and corresponding span permissions; and the authentication identifier indicates whether supplementary authentication is required. The second chain is formed using the server frequency and metadata of the requested data; Combining the first chain and the second chain to obtain a secure access chain; S4. Perform access verification based on the generated security access chain, including time window verification, data access permission verification, and access frequency verification; S5. Obtain access verification results. If data access permission verification, access frequency verification, and time window verification are all passed, identity authentication is performed based on the security access chain. S6. Obtain the identity authentication result. After the identity authentication is passed, the server generates an encryption key based on the security access chain, encrypts the requested data, and sends it to the client. The client generates the corresponding decryption key to decrypt the received data.

2. A method for secure access to electric power cloud data according to claim 1, characterized in that: The request packet header includes the data transmission protocol version number and checksum; the request packet body includes basic information and a digital certificate; the basic information includes request type, request target, request span, timestamp and requester information.

3. A method for secure access to electric power cloud data according to claim 2, characterized in that: The request verification includes: Calculate the checksum of the access request packet and compare the calculated checksum with the checksum provided in the request packet header; if they are the same, perform protocol verification; if they are different, determine the request verification result as failed; The protocol verification includes: obtaining a data transmission protocol version number and comparing it with a list of data transmission protocol version numbers supported by the server; If the same data transmission protocol version number is not found, the request verification result is judged as failed; If the same data transmission protocol version number is found, the transmission protocol rule corresponding to the data transmission protocol version number is extracted, and the request packet is checked to see if it complies with the transmission protocol rule; If it meets the requirements, the request verification result is judged as passed; if it does not meet the requirements, the request verification result is judged as failed.

4. A method for secure access to electric power cloud data according to claim 3, characterized in that: The time window verification includes obtaining the timestamp and window time in the security access chain and determining whether the timestamp is within the window time; If not, the time window verification fails; if so, the time difference is obtained by subtracting the current time from the timestamp to determine whether the time difference is within the preset time difference range; If yes, the time window verification passes; If otherwise, the time window verification fails; The data access permission verification includes: obtaining the permission number and requester information in the security access chain, obtaining the permission table according to the permission number, and checking whether the requester is an authorized user in the permission table; If not, the data access permission verification fails; if so, the corresponding span permission is obtained to determine whether the requested span in the security access chain is within the span permission; If yes, the data access permission verification is passed; if no, the data access permission verification is failed; The access frequency verification includes: obtaining the server frequency and the allowed frequency in the security access chain, and judging whether the request frequency is not greater than the allowed frequency. If so, the access frequency verification passes; otherwise, the access frequency verification fails.

5. A method for secure access to electric power cloud data according to claim 4, characterized in that: The steps of performing identity authentication according to the security access chain include: Obtain digital certificates and verify them; When the digital certificate verification fails, it is determined that the identity authentication fails; When the digital certificate is verified, the authentication identifier of the secure access chain is obtained; If the authentication flag is no, the identity authentication is determined to be successful; If the certification mark is yes, then supplementary certification is performed; If the supplementary authentication passes, the identity authentication is determined to be passed; otherwise, the identity authentication fails.

6. A method for secure access to electric power cloud data according to claim 5, characterized in that: The steps of the supplementary certification include: Obtain the public key from the digital certificate, generate a random challenge code on the server side, and combine the challenge code and generation time into the information to be signed; The information to be signed is sent to the client, which uses the private key to digitally sign the information to be signed and returns the signature result to the server; The server uses the public key to decrypt the signature result and determines whether the decrypted signature result is consistent with the information to be signed. At the same time, it determines whether the difference between the generation time in the decrypted signature result and the current time is within a preset range; When both of the above judgment results are yes, the supplementary authentication is determined to be passed; otherwise, the supplementary authentication is determined to be failed.

7. A method for secure access to electric power cloud data according to claim 6, characterized in that: The steps of generating the encryption key include: obtaining a request type, a timestamp, requester information, and a server frequency in the security access chain; generating an encryption key using a key generation algorithm according to the request type, timestamp, requester information, and server frequency; The steps for generating the decryption key include: obtaining the request type, timestamp, requester information and request target in the access request package, obtaining the request frequency of the requester for the request target recorded by the client and recording it as the client frequency; using the same key generation algorithm to generate the decryption key based on the request type, timestamp, requester information and client frequency in the access request package.

8. A power cloud data security access system, used to implement a power cloud data security access method according to any one of claims 1 to 7, characterized in that: include: A request packet construction module, configured for the client to construct and send an access request packet for power cloud data, wherein the access request packet includes a request packet header and a request packet body; The request verification module is used for receiving the access request packet at the server side and performing request verification on the access request packet according to the request packet header; The security chain generation module is used to obtain the request verification result, extract the request package body for the access request package that passes the request verification, and generate a security access chain based on the extracted request package body; The step of generating a security access chain according to the extracted request packet body includes: Get the basic information in the request package body; Use the request type, request target, request span, timestamp, and requester information in the basic information to form the first chain; According to the requester information and the request target, the request frequency of the requester to the request target is obtained from the server side and recorded as the server frequency; Obtain metadata for the request target, including type, permission number, window time, allowed frequency, and authentication identifier; wherein the permission number corresponds to a permission table, which includes authorized users and corresponding span permissions; and the authentication identifier indicates whether supplementary authentication is required. The second chain is formed using the server frequency and metadata of the requested data; Combining the first chain and the second chain to obtain a secure access chain; Access verification module, used to perform access verification based on the generated security access chain, including data access permission verification, access frequency verification, and time window verification; The identity authentication module is used to obtain access verification results. When data access permission verification, access frequency verification, and time window verification are all passed, identity authentication is performed according to the security access chain. The data security transmission module is used to obtain the identity authentication result. After the identity authentication is passed, the server generates an encryption key based on the security access chain, encrypts the requested data and sends it to the client. The client generates the corresponding decryption key to decrypt the received data.

Images