A power system lightweight secure communication method, device, equipment and medium

Abstract

The application discloses a kind of power system lightweight security communication method, device, equipment and medium, the power system lightweight security communication method proposes a kind of combination matrix certificateless key generation driven by accompanying public key and the combination of layered seed cache based on timing-load joint scheduling lightweight communication measures, the key of this measure is to couple terminal short-term random material, such as accompanying public key / epoch and combination matrix index mechanism, to realize the forward security private key rotation of provable;And session encryption block generation is changed from static presetting to timing-load joint adaptive scheduling and layered cache, while designing collaborative leakage response and cache security recovery mechanism, so that provable security and efficient communication are considered under strict resource constraints, to ensure the security, efficiency, adaptability and robustness of data transmission carried out by power system resource-constrained terminal.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of power communication, in particular, to a power system lightweight secure communication method, device, equipment and medium. BACKGROUND

[0002] With the development of smart grid and power distribution automation, the number of limited terminal devices accessed in the power internet of things has increased rapidly, among which a large number of nodes (such as smart meters, sensors, etc.) are strictly limited in computing power, memory and power. The deployment cost of the traditional public key infrastructure (PKI) based digital certificate system is high, and the verification delay is large, which is difficult to meet the real-time and low-power communication demand in the resource-limited environment.

[0003] Therefore, the academic and industrial circles have proposed several lightweight secure communication schemes to reduce the authentication and encryption overhead:

[0004] First, the "combination matrix / combination public key (CPK)" type certificateless index generates a temporary public key by combining matrix elements to avoid certificate overhead;

[0005] Second, the "pre-computed cache" type generates random key stream fragments offline and caches them to limited terminals to reduce online computation.

[0006] Although the above two types of schemes can reduce the real-time computation cost, they generally have the following shortcomings:

[0007] Key update mechanism is insufficient: most schemes rely on long-term or semi-long-term keys, lack dynamic key derivation and rotation mechanism bound to communication session state or device running context (such as power, load), and forward security guarantee is incomplete; Cache strategy is static and rigid: the rate of pre-generated encryption blocks and cache queue management are mostly static settings, which cannot be adjusted adaptively according to the real-time resource state of limited terminals (such as CPU load, remaining power), and may cause resource waste or security performance degradation; Weak anti-leakage and recovery capability: once potential leakage of keys or cache materials is detected, there is a lack of fast and coordinated security recovery and key revocation mechanism, the response delay is high, and the systematic risk still exists; Key function is single: usually derived session keys are single-purpose, key reuse degree between different security functions (such as encryption, authentication, cache seed) is high, and key usage is not strictly isolated, which increases the horizontal risk caused by key leakage. SUMMARY

[0008] The present application provides a power system lightweight secure communication method, which solves the technical problems of insufficient security, poor adaptability and poor robustness of existing power communication schemes.

[0009] The present application is implemented by the following scheme:

[0010] A lightweight secure communication method for power systems includes the following steps:

[0011] Restricted terminals apply for certificateless key materials from the key center by introducing a time window and a one-time random number, and the materials are then distributed to the restricted terminals. Lightweight hash-based message authentication code (HMAC) is used for integrity verification to achieve certificateless key application.

[0012] The key center and the restricted terminal each use a short-term private key to generate a local private key for the restricted terminal, and trigger a private key update and discard the old session key when the restricted terminal period epoch switches or an anomaly occurs.

[0013] The restricted terminal generates an intermediate public key based on the accompanying public key, adds the intermediate public key to the accompanying public key to generate the restricted terminal public key, and establishes a certificateless trust chain by combining the restricted terminal's local private key for signature verification.

[0014] Based on the session key calculated between communication-restricted terminals using their own private key and the other party's public key, and the identity identifiers of both parties as inputs to the key derivation function KDF, a multi-purpose key for encryption, message authentication, and encryption block derivation is derived to achieve lightweight session key negotiation.

[0015] A hierarchical queuing, block aging, and CPU / power-aware production rate control strategy is adopted to divide the cache into high-priority and low-priority queues, and dynamically adjust the pre-encrypted packet generation rate according to CPU load and power level.

[0016] When a restricted terminal detects a risk of key material leakage, it monitors the cryptographic calculation error rate, identifies abnormal communication patterns, receives security alarms from the key center, or triggers physical anti-tampering sensors; and when a risk is detected, it triggers an emergency key rotation process in coordination with the key center.

[0017] Furthermore, the restricted terminal applies for certificate-free key materials from the key center by introducing a time window and a one-time random number, and the materials are then distributed to the restricted terminal. Lightweight hash-based message authentication code (HMAC) is used for integrity verification to achieve certificate-free key application. The specific steps include:

[0018] Restricted terminal generates one-time random numbers Then, combined with their own identity markers and the current time window Calculate the hash value: ;

[0019] Restricted terminals use hash values Using the public key matrix as an index, a temporary public key is generated by combining elements from the public key matrix. ;

[0020] Restricted terminal generates temporary session key Using a temporary public key Encrypt and attach a lightweight HMAC tag: ;

[0021] Restricted terminal sends encrypted data packets To the key center;

[0022] Key Center Verification Time Window and After validation, generate using the same indexing method. And decrypt ,check ;

[0023] The key center uses temporary session keys. The key material is encrypted and then sent to restricted terminals.

[0024] Furthermore, the key center maintains a sliding time window of length L and stores the most recent M one-time random numbers. To achieve deduplication, during decryption, the same indexing function as that used by restricted terminals is employed to select m public key elements from the public key matrix and generate a temporary public key using elliptic curve point addition. .

[0025] Furthermore, the key center and the restricted terminal each use a short-term private key to generate a local private key for the restricted terminal, and trigger a private key update and discard the old session key when the restricted terminal switches epochs or encounters an anomaly. The specific steps include:

[0026] The key center and restricted terminals exchange short-term random public keys on an epoch-period basis. Add a public key to generate an accompanying key. ;

[0027] The key center obtains the index value based on the restricted terminal identifier. Then, a set of private key elements is selected from the private key matrix and combined to obtain the intermediate private key. ;

[0028] The key center and restricted terminals each use short-term private keys. To generate the final private key, the key center first calculates the private key. It is then sent to the restricted terminal, which then calculates its local private key. ;

[0029] When a restricted terminal detects an epoch switch or an anomaly, it immediately discards / overwrites the relevant session key locally and reports to the key center, triggering a private key update and discarding the old session key.

[0030] Furthermore, the restricted terminal generates an intermediate public key based on the accompanying public key, adds the intermediate public key to the accompanying public key to generate the restricted terminal's public key, and uses this public key to sign and verify the signature, establishing a certificateless trust chain. The specific steps include:

[0031] Restricted terminals based on accompanying public key With identity markers Indexing public key matrix elements, dot-matrix addition generates intermediate public key. ;

[0032] Restricted terminals will use the intermediate public key With accompanying public key Get the restricted terminal public key by clicking. ;

[0033] Restricted terminals use local private keys For including time windows and nonce T SMS Generate signature To provide proof of consistency;

[0034] Communication peer receives and After verifying consistency, a certificate-free trust chain is established.

[0035] Furthermore, based on the session key calculated between the communication-restricted terminals using their own private key and the other party's public key, and the identity identifiers of both parties as inputs to the key derivation function KDF, a multi-purpose key for encryption, message authentication, and encryption block derivation is derived, thus achieving lightweight session key negotiation. The specific steps include:

[0036] Both communicating parties, A and B, calculate each other's public key locally. , ;

[0037] Each entity collaborates with a key center to calculate its own private key. , ;

[0038] The session key is calculated by multiplying the user's private key by the other party's public key. Restricted terminal A then calculates the session key. Restricted terminal B calculates the session key ;

[0039] The communicating parties use the obtained session key and their respective identity identifiers as inputs to the KDF to derive a multi-purpose key for encryption, message authentication, and encryption block derivation. The key material includes: the current epoch value, the accompanying public key R, and the identity identifiers (IDs) of the communicating parties A and B. A ID BThe KDF uses an HKDF or an equivalent HMAC-based key derivation function.

[0040] Furthermore, a hierarchical queuing, block aging, and CPU / power-aware production rate control strategy is adopted. The cache is divided into high-priority and low-priority queues, and the specific calculation formula for dynamically adjusting the pre-encrypted packet generation rate based on CPU load and power level is as follows:

[0041] ;

[0042] Where, clamp is the truncation function; in the example values ​​of the embodiment, battery_level represents the terminal's battery level, CPU_load represents the terminal's current CPU load, α is the CPU load threshold, β is the battery level threshold, k1 is the CPU load weight, k2 is the battery level weight, R_min is the minimum cache generation rate, R_base is the base cache generation rate, and R_max is the maximum cache generation rate.

[0043] Furthermore, upon detecting a risk, an emergency key rotation process in collaboration with the key center is triggered, specifically including the following steps:

[0044] The key center synchronizes emergency status with restricted terminals and invalidates key materials related to the affected epoch;

[0045] Based on the newly generated accompanying public key, the next-generation key is recalculated using restricted terminal private key generation, restricted terminal public key generation, and the minimum update key material issued by the key center.

[0046] Automatically identify encrypted blocks in the cache that are associated with the affected epoch or key identifier, and securely reclaim them by overwriting data;

[0047] Generate audit credentials and transmit them to the key center.

[0048] This application also provides a lightweight security communication device for power systems, comprising:

[0049] The certificateless key application module is used by restricted terminals to apply for certificateless key materials from the key center by introducing a time window and a one-time random number and then distribute them to the restricted terminals. Lightweight hash-based message authentication code HMAC is used for integrity verification to realize the certificateless key application.

[0050] The restricted terminal private key generation module is used by the key center and the restricted terminal to generate local private keys for the restricted terminal using short-term private keys, and to trigger private key updates and discard old session keys when the restricted terminal epoch switches or an abnormality occurs.

[0051] The restricted terminal public key generation module is used to generate an intermediate public key based on the accompanying public key of the restricted terminal, add the intermediate public key and the accompanying public key to generate the restricted terminal public key, and combine it with the local private key of the restricted terminal to sign and verify to establish a certificateless trust chain.

[0052] The lightweight session key negotiation module is used to derive a multi-purpose key for encryption, message authentication and encryption block derivation based on the session key calculated between communication-restricted terminals using their own private key and the other party's public key, and the identity identifiers of both parties as inputs to the key derivation function KDF, thereby realizing lightweight session key negotiation.

[0053] The encrypted block cache module is used to divide the cache into high-priority and low-priority queues using a hierarchical queue, block aging and CPU / power-aware production rate control strategy, and dynamically adjust the pre-encrypted packet generation rate according to CPU load and power level.

[0054] The collaborative leakage response and security recycling module is used to monitor the cryptographic calculation error rate, identify abnormal communication patterns, receive security alarms from the key center, or trigger physical anti-tamper sensors when a restricted terminal detects the risk of key material leakage; and triggers an emergency key rotation process in collaboration with the key center when a risk is detected.

[0055] This application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the lightweight secure communication method for the power system.

[0056] This application also provides a storage medium including a stored program that, when the program is executed, controls the device where the storage medium is located to perform the steps of the power system lightweight secure communication method.

[0057] Compared with the prior art, this application has the following advantages:

[0058] 1. This application achieves true dynamic forward security with more granular and reliable key management: By introducing an accompanying public key R bound to short epochs and a rotation mechanism, the private key of the restricted terminal is no longer long-term or semi-static, but dynamically updated with the session cycle. This fundamentally solves the problems of insufficient key updates and weak forward security in the closest approximation scheme, ensuring that even if the current key is leaked, past sessions will not be decrypted, significantly improving the security of long-term communication;

[0059] 2. This application's caching strategy changes from static to load-aware, resulting in more efficient and intelligent resource utilization: Unlike the rigid static cache generation strategies in existing technologies, this application pioneers a hierarchical cache queue and dynamic rate adjustment mechanism based on real-time CPU load and power levels. This allows cache block generation to adapt to the current resource state of the limited terminal, intelligently slowing down to save resources under high load or low power, and accelerating to improve performance when resources are sufficient, achieving the best balance between security performance and resource consumption, and avoiding resource waste or a sudden drop in security performance;

[0060] 3. This application establishes a collaborative and proactive security recycling and emergency response mechanism, resulting in stronger resistance to data leakage: when the system detects a potential risk of key or random number leakage, it can automatically trigger an emergency key rotation process in collaboration with the key center, and securely discard and overwrite the affected cache blocks. This mechanism overcomes the passive situation of weak recovery capabilities and high response latency in the closest approximation scheme, achieving rapid response and isolation to security threats, and greatly enhancing the overall resilience and security of the system;

[0061] 4. This application achieves functional isolation of keys and features a more rigorous security design: Different subkeys for encryption, message authentication codes, and cache seed generation are derived from the master key via the Key Derivation Function (KDF), strictly avoiding the lateral risks associated with single-key reuse in the closest matching scheme. Even if one subkey is leaked, the other functional keys remain secure, achieving a deeper level of security defense.

[0062] 5. Under the same resource constraints, this application provides higher comprehensive security and communication performance: This application does not sacrifice performance for security, but through a series of lightweight designs (such as lightweight HMAC verification, combined matrix indexing, and XOR stream encryption), it achieves security, adaptability and reliability far exceeding the closest existing technologies under the same or even lower resource overhead, perfectly meeting the stringent requirements of power Internet of Things restricted terminals.

[0063] In addition to the purposes, features, and advantages described above, this application has other purposes, features, and advantages. A further detailed description of this application will be provided below with reference to the figures. Attached Figure Description

[0064] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0065] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort, wherein:

[0066] Figure 1 This is a schematic flowchart of a lightweight secure communication method for power systems according to a preferred embodiment of this application;

[0067] Figure 2 This is a system architecture diagram of the lightweight secure communication method for power systems that implements the present application;

[0068] Figure 3 This is a schematic diagram of a lightweight secure communication device module for a power system according to a preferred embodiment of this application;

[0069] Figure 4 This is a schematic block diagram of an electronic device according to a preferred embodiment of this application;

[0070] Figure 5 This is an internal structural diagram of a computer device according to a preferred embodiment of this application. Detailed Implementation

[0071] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0072] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0073] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or a lightweight secure communication device for power systems capable of performing the above functions. The following description uses a lightweight secure communication device for power systems as the executing entity to illustrate this embodiment and the subsequent embodiments.

[0074] like Figure 2 As shown, a preferred embodiment of this application provides a lightweight secure communication method for power systems, including the following steps:

[0075] S1. The restricted terminal applies for certificateless key materials from the key center by introducing a time window and a one-time random number and distributes them to the restricted terminal. Lightweight hash-based message authentication code HMAC is used for integrity verification to realize the application for certificateless key.

[0076] S2, the key center and the restricted terminal each use a short-term private key to generate a local private key for the restricted terminal, and trigger a private key update and discard the old session key when the restricted terminal period epoch switches or an anomaly occurs.

[0077] S3. The restricted terminal generates an intermediate public key based on the accompanying public key, adds the intermediate public key to the accompanying public key to generate the restricted terminal public key, and establishes a certificateless trust chain by combining the restricted terminal's local private key for signature verification.

[0078] S4. Based on the session key calculated between the communication-restricted terminals using their own private key and the other party's public key, and the identity identifiers of both parties as inputs to the key derivation function KDF, a multi-purpose key for encryption, message authentication, and encryption block derivation is derived to achieve lightweight session key negotiation.

[0079] S5. A production rate control strategy based on hierarchical queuing, block aging, and CPU / power awareness is adopted to divide the cache into high-priority and low-priority queues and dynamically adjust the pre-encrypted packet generation rate according to CPU load and power level.

[0080] S6. When the restricted terminal detects the risk of key material leakage, it monitors the cryptographic calculation error rate, identifies abnormal communication patterns, receives security alarms from the key center, or triggers physical anti-tampering sensors; and when a risk is detected, it triggers an emergency key rotation process in coordination with the key center.

[0081] Compared with the prior art, this embodiment has the following beneficial effects:

[0082] 1. This embodiment achieves true dynamic forward security and more granular and reliable key management: by introducing an accompanying public key R bound to short epochs and a rotation mechanism, the private key of the restricted terminal is no longer long-term or semi-static, but dynamically updated with the session cycle. This fundamentally solves the problems of insufficient key updates and weak forward security in the closest approximation scheme, ensuring that even if the current key is leaked, past sessions will not be decrypted, significantly improving the security of long-term communication;

[0083] 2. The caching strategy in this embodiment changes from static to load-aware, resulting in more efficient and intelligent resource utilization: Unlike the rigid static cache generation strategy in existing technologies, this application pioneers a hierarchical cache queue and dynamic rate adjustment mechanism based on real-time CPU load and power levels. This allows cache block generation to adapt to the current resource state of the limited terminal, intelligently slowing down to save resources under high load or low power, and accelerating to improve performance when resources are sufficient, achieving the best balance between security performance and resource consumption, and avoiding resource waste or a sudden drop in security performance;

[0084] 3. This embodiment establishes a collaborative and proactive security recycling and emergency response mechanism, resulting in stronger resistance to data leakage: when the system detects a potential risk of key or random number leakage, it can automatically trigger an emergency key rotation process in collaboration with the key center, and securely discard and overwrite the affected cache blocks. This mechanism overcomes the passive situation of weak recovery capabilities and high response latency in the closest approximation solution, achieving rapid response and isolation to security threats, and greatly enhancing the overall resilience and security of the system;

[0085] 4. This embodiment achieves functional isolation of keys and features a more rigorous security design: Different subkeys for encryption, message authentication codes, and cache seed generation are derived from the master key using a Key Derivation Function (KDF), strictly avoiding the lateral risks associated with single-key reuse in the closest matching scheme. Even if one subkey is leaked, the other functional keys remain secure, achieving a deeper level of security defense.

[0086] 5. Under the same resource constraints, this application provides higher comprehensive security and communication performance: This application does not sacrifice performance for security, but through a series of lightweight designs (such as lightweight HMAC verification, combined matrix indexing, and XOR stream encryption), it achieves security, adaptability and reliability far exceeding the closest existing technologies under the same or even lower resource overhead, perfectly meeting the stringent requirements of power Internet of Things restricted terminals.

[0087] In a preferred embodiment of this application, the restricted terminal requests certificate-free key materials from the key center and distributes them to the restricted terminal by introducing a time window and a one-time random number. Lightweight hash-based message authentication code (HMAC) is used for integrity verification to achieve certificate-free key application. The specific steps include:

[0088] S11. Restricted terminal generates a one-time random number. Then, combined with their own identity markers and the current time window Calculate the hash value: ;

[0089] S12, Restricted terminals use hash values Using the public key matrix as an index, a temporary public key is generated by combining elements from the public key matrix. ;

[0090] S13. Restricted terminal generates temporary session key. Using a temporary public key Encrypt and attach a lightweight HMAC tag: ;

[0091] S14. Restricted terminal sends encrypted data packets. To the key center;

[0092] S15, Key Center Verification Time Window and After validation, generate using the same indexing method. And decrypt ,check ;

[0093] S16. The key center uses a temporary session key. The key material is encrypted and then sent to restricted terminals.

[0094] Specifically, the key center maintains a sliding time window of length L and stores the most recent M one-time random numbers. To achieve deduplication, during decryption, the same indexing function as that used by restricted terminals is employed to select m public key elements from the public key matrix and generate a temporary public key using elliptic curve point addition. Among them, P1, P2...P m These represent the elliptic curve points at the corresponding index positions in the selected public key matrix. In this embodiment, L = 300 seconds, M = 65536, and m = 3~8.

[0095] This embodiment specifically implements certificateless key application through steps S11~S16. Its advantages include achieving a balance between security (authentication, freshness, forward security) and engineering feasibility (low computing power, low bandwidth, scalability), which is an effective improvement over existing PKI / static caching schemes.

[0096] In a preferred embodiment of this application, the key center and the restricted terminal each use a short-term private key to generate a local private key for the restricted terminal, and trigger a private key update and discard the old session key when the restricted terminal's epoch switches or an anomaly occurs. Specifically, the steps include:

[0097] S21. The key center and restricted terminals exchange short-term random public keys periodically (epochs). Add a public key to generate an accompanying key. ;

[0098] S22. The key center obtains the index value based on the restricted terminal identifier. Then, a set of private key elements is selected from the private key matrix and combined to obtain the intermediate private key. ;

[0099] S23, the key center, and the restricted terminal each use short-term private keys. To generate the final private key, the key center first calculates the private key. It is then sent to the restricted terminal, which then calculates its local private key. ;

[0100] S24. When a restricted terminal detects a periodic epoch switch or an anomaly, it immediately discards / overwrites the relevant session key locally and reports to the key center, triggering a private key update and discarding the old session key.

[0101] This embodiment specifically implements the generation and updating of local private keys for restricted terminals through steps S21 to S24. Its advantages include: it can maintain a lightweight implementation while taking into account the security, flexibility and auditability of private keys, and solves the problems of difficult key updates and insufficient forward security in the prior art for resource-constrained terminals.

[0102] In a preferred embodiment of this application, the restricted terminal generates an intermediate public key based on the accompanying public key, adds the intermediate public key to the accompanying public key to generate the restricted terminal public key, and establishes a certificateless trust chain by combining the restricted terminal's local private key for signature verification. The specific steps include:

[0103] S31, Restricted terminals based on accompanying public key With identity markers Indexing public key matrix elements, dot-matrix addition generates intermediate public key. ;

[0104] S32, The restricted terminal will transfer the intermediate public key With accompanying public key Get the restricted terminal public key by clicking. ;

[0105] S33, Restricted terminals use local private keys For including time windows and nonce T SMS Generate signature To provide proof of consistency;

[0106] S34, Communication peer receives and After verifying consistency, a certificate-free trust chain is established.

[0107] This embodiment specifically implements the generation and updating of the local public key of the restricted terminal through steps S31 to S34. Its advantages include: not only ensuring the consistency of the public key and authentication capability of the restricted terminal in a certificateless environment, but also improving the security, scalability and engineering feasibility of the system.

[0108] In a preferred embodiment of this application, a multi-purpose key for encryption, message authentication, and encryption block derivation is derived from a session key calculated between communication-restricted terminals based on their own private key and the other party's public key, and the identity identifiers of both parties as inputs to the key derivation function KDF, thereby achieving lightweight session key negotiation. The specific steps include:

[0109] S41. Both communicating parties A and B calculate each other's public key locally. , ;

[0110] S42. Each entity collaborates with the key center to calculate its own private key. , ;

[0111] S43. Calculate the session key by performing a dot product between your private key and the other party's public key. Restricted terminal A calculates the session key. Restricted terminal B calculates the session key ;

[0112] S44. The two communicating parties use the obtained session key and their respective identity identifiers as KDF inputs to derive a multi-purpose key for encryption, message authentication, and encryption block derivation. The key material includes: the current epoch value, the accompanying public key R, and the identity identifiers (IDs) of the two communicating parties A and B. A ID B The KDF uses an HKDF or an equivalent HMAC-based key derivation function.

[0113] The encrypted block has a block size of 16 bytes and a maximum queue length of 1024 blocks. Each encrypted block is identified by a quadruple (source IP, destination IP, source port, destination port) and a block number. The sending end performs an XOR operation on the plaintext block and one or more selected encrypted blocks to generate ciphertext. The receiving end performs an XOR operation on the ciphertext using the same encrypted block sequence to decrypt it and obtain the plaintext.

[0114] For both communicating parties, when calculating their own private key, the other party's public key, and the session key, the elements such as their random private key, random public key, and identity identifier are shown in Table 1 below (taking communicating party A, communicating party B, and key center K as an example):

[0115] Table 1

[0116]

[0117] This embodiment specifically performs multi-purpose key derivation through steps S41 to S44, realizing lightweight session key negotiation. Its advantages include: functional isolation reduces lateral risk, and through KDF derivation and context binding, the leakage of any single subkey will not compromise the confidentiality of other security functions.

[0118] Preferably, a hierarchical queuing, block aging, and CPU / power-aware production rate control strategy is adopted. The cache is divided into high-priority and low-priority queues, and the specific calculation formula for dynamically adjusting the pre-encrypted packet generation rate based on CPU load and power level is as follows:

[0119] ;

[0120] Where, `clamp` is the truncation function; `battery_level` represents the terminal's battery level percentage; `CPU_load` represents the terminal's current CPU load; `α` is the CPU load threshold; `β` is the battery level threshold; `k1` is the CPU load weight; `k2` is the battery level weight; `R_min` is the minimum cache generation rate; `R_base` is the base cache generation rate; and `R_max` is the maximum cache generation rate. In this embodiment, the CPU load threshold `α` = 0.75, the battery level threshold `β` = 0.45, the CPU load weight `k1` = 0.75, the battery level weight `k2` = 0.5, the minimum cache generation rate `R_min` = 5 blocks / s, the base cache generation rate `R_base` = 100 blocks / s, and the maximum cache generation rate `R_max` = 200 blocks / s.

[0121] This embodiment employs a hierarchical queuing, block aging, and CPU / power-aware production rate control strategy. The cache is divided into high-priority and low-priority queues, and the pre-encryption packet generation rate is dynamically adjusted based on CPU load and power level. Its advantages include: changing from static generation to time-load joint scheduling, which can dynamically reduce the generation rate to save resources under high load or low power, and increase the rate to reduce real-time encryption latency when resources are sufficient, thereby improving communication performance with the same or lower resource consumption.

[0122] In a preferred embodiment of this application, upon detection of a risk, an emergency key rotation process coordinated with the key center is triggered, specifically including the following steps:

[0123] S61. The key center synchronizes the emergency status with the restricted terminal and invalidates the key materials related to the affected epoch.

[0124] S62. Based on the newly generated accompanying public key, recalculate the next-generation key using the restricted terminal private key generation, the restricted terminal public key generation, and the minimal update key material issued by the key center.

[0125] S63. Automatically identify encrypted blocks in the cache that are associated with the affected epoch or key identifier and securely reclaim them by overwriting data.

[0126] S64. Generate audit credentials and transmit them to the key center.

[0127] This embodiment specifically implements the process of triggering an emergency key rotation in collaboration with the key center when a risk is detected through steps S61 to S64. Its advantages include: ensuring forward security, covering old materials and completing the binding of new keys; and providing auditable evidence to support post-analysis and compliance checks.

[0128] Figure 2 This is a system architecture diagram for implementing the lightweight secure communication method for power systems of the present invention. The architecture consists of three types of entities and five functional modules: a key center (K), restricted terminals (or multiple restricted terminals), and peer-to-peer communication / cloud services. The interaction between the restricted terminals and the key center includes: certificateless application, private / public key material exchange, and emergency synchronization. The interaction between the restricted terminals and the terminal / cloud service includes: data encryption / decryption using negotiated session keys and cache seeds. The key center is responsible for centralized management and trusted support for restricted terminals, and includes three sub-modules: key matrix management, terminal authentication, and terminal key management. Key matrix management is used to store and maintain combined public and private key matrices (including version / epoch information, indexing rules, element update and obsolescence lists), and provides matrix query / composite interfaces to other sub-modules or terminals.

[0129] Terminal identity authentication is used to verify the identity of the applicant's terminal (the freshness / consistency of the application materials) and prevent forgery / replay.

[0130] Terminal key management is used to collaborate with terminals to generate, distribute, rotate, and revoke short-term private / public key materials; and to maintain terminal key status (current epoch, list of revoked epochs, and emergency retrieval records).

[0131] The restricted terminal is internally divided into three main sub-modules: key management, session management, and cryptographic block cache.

[0132] Key management is used to perform local key combination, storage and rotation of private / public keys on the terminal side (in conjunction with auxiliary materials provided by the key center), and to maintain the interface with session management.

[0133] Session management is used to complete session negotiation using a combination of the local private key and the peer's public key, derive subkeys from KDF, and provide key services (encryption, authentication) for upper-layer applications.

[0134] Encryption block caching is used to pre-generate and cache a number of encryption blocks (seed blocks) locally on the terminal so that encryption can be completed by low-overhead XOR / streaming mixing when sending, reducing the online computing burden.

[0135] The solutions provided in the above embodiments are compatible with MQTT and CoAP protocols as cloud / edge communication bearer layers; and can selectively run on HarmonyOS or equivalent operating systems such as Zephyr and FreeRTOS, wherein the equivalent operating system refers to an operating system that provides built-in encryption component hardware drivers or instruction sets; the partial computation refers to implementing one or more of the following computations by calling the built-in encryption component hardware drivers or instruction sets of the operating system: elliptic curve point addition, point multiplication, AES encryption and decryption, and secure hash algorithms.

[0136] In summary, the lightweight secure communication method for power systems provided in the above embodiments of this application includes the following innovative features:

[0137] 1) Certificate-free indexing of a combined matrix driven by public keys: The terminal generates a short-lived random public key R in each short epoch, combines it with a device-fixed identity index, selects elements from the combined public / private key matrix according to a provable indexing function, and performs a fixed-point addition sequence to form a temporary public / private key pair. This process is designed to be security-specifically described using formal semantics, rather than a simple matrix superposition.

[0138] 2) Timing-Load Coordinated Tiered Seed Cache: Introducing "seed-tier" and "session popularity" metrics, encrypted blocks are generated and managed across multiple priority queues. The seed generation rate is dynamically adjusted via a joint function based on real-time measurements of CPU utilization, battery level, and session revisit rate (using constrained proportional control and retaining a two-stage strategy of rapid derating and slow rebound to avoid oscillations).

[0139] 3) Multi-functional Key Derivation and Functional Isolation: The session master key derives three independent subkeys from a verified KDF (e.g., HKDF): K_enc (used only as a cryptographic seed for XOR / streaming hybrid encryption), K_mac (used for lightweight message authentication, such as truncated-HMAC), and K_seed (used for pseudo-random cryptographic block generation). Different contextual information (identity, epoch, direction bit) is used as info input to ensure functional isolation and context binding, preventing lateral misuse.

[0140] 4) Time window and non-replay proof for certificateless requests: A dual mechanism is introduced in certificateless requests—a short time window (epoch granularity) and a non-replay set based on random numbers (deduplication is implemented in the key center in the form of a scalable counter or Bloom filter), and lightweight MAC is used to prove the consistency and freshness of messages, preventing replay and reuse of requests;

[0141] 5) Collaborative Leakage Response and Secure Reclamation: Once an anomaly is detected (local detection or key center alarm), a collaborative reclamation process is triggered: ① Discard the relevant blocks in the affected seed-tier; ② Trigger an epoch rotation with the accompanying public key; ③ Overwrite the cached blocks online (obfuscated with the new seed) and record reclamation evidence for auditing;

[0142] 6) Lightweight implementation compatibility: For optional terminal implementations, local hardware acceleration / built-in encryption primitives (such as ECC dot addition and AES) are prioritized to complete a small number of critical operations. The rest are handled by simple XOR and truncated HMAC to reduce normal computational overhead, ensuring that lightweight computing is achieved while having anti-replay and anti-reuse characteristics.

[0143] like Figure 3 As shown, this application also provides a lightweight security communication device for power systems, comprising:

[0144] The certificateless key application module is used by restricted terminals to apply for certificateless key materials from the key center by introducing a time window and a one-time random number and then distribute them to the restricted terminals. Lightweight hash-based message authentication code HMAC is used for integrity verification to realize the certificateless key application.

[0145] The restricted terminal private key generation module is used by the key center and the restricted terminal to generate local private keys for the restricted terminal using short-term private keys, and to trigger private key updates and discard old session keys when the restricted terminal epoch switches or an abnormality occurs.

[0146] The restricted terminal public key generation module is used to generate an intermediate public key based on the accompanying public key of the restricted terminal, add the intermediate public key and the accompanying public key to generate the restricted terminal public key, and combine it with the local private key of the restricted terminal to sign and verify to establish a certificateless trust chain.

[0147] The lightweight session key negotiation module is used to derive a multi-purpose key for encryption, message authentication and encryption block derivation based on the session key calculated between communication-restricted terminals using their own private key and the other party's public key, and the identity identifiers of both parties as inputs to the key derivation function KDF, thereby realizing lightweight session key negotiation.

[0148] The encrypted block cache module is used to divide the cache into high-priority and low-priority queues using a hierarchical queue, block aging and CPU / power-aware production rate control strategy, and dynamically adjust the pre-encrypted packet generation rate according to CPU load and power level.

[0149] The collaborative leakage response and security recycling module is used to monitor the cryptographic calculation error rate, identify abnormal communication patterns, receive security alarms from the key center, or trigger physical anti-tamper sensors when a restricted terminal detects the risk of key material leakage; and triggers an emergency key rotation process in collaboration with the key center when a risk is detected.

[0150] The lightweight secure communication device for power systems provided in this application, employing the lightweight secure communication method for power systems described in the above embodiments, can solve the technical problems of insufficient security, poor adaptability, and poor robustness in existing power communication schemes. Compared with the prior art, the beneficial effects of the lightweight secure communication device for power systems provided in this application are the same as those of the lightweight secure communication method for power systems provided in the above embodiments, and other technical features in the lightweight secure communication device for power systems are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0151] like Figure 4 As shown, a preferred embodiment of this application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps of the lightweight secure communication method for power systems described in the above embodiments.

[0152] The electronic device provided in this application employs the lightweight secure communication method for power systems described in the above embodiments, which can solve the technical problems of insufficient security, poor adaptability, and poor robustness in existing power communication schemes. Compared with the prior art, the beneficial effects of the electronic device provided in this application are the same as those of the lightweight secure communication method for power systems provided in the above embodiments, and other technical features of the electronic device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0153] like Figure 5 As shown, a preferred embodiment of this application also provides a computer device, which may be a restricted terminal or a liveness detection server, and its internal structure diagram may be as follows. Figure 5 As shown. The computer device includes a processor, memory, and a network interface connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The network interface is used to communicate with other external computer devices via a network connection. When the computer program is executed by the processor, it implements the steps of the aforementioned lightweight secure communication method for power systems.

[0154] Those skilled in the art will understand thatFigure 5 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0155] The computer device provided in this application, employing the lightweight secure communication method for power systems described in the above embodiments, can solve the technical problems of insufficient security, poor adaptability, and poor robustness in existing power communication schemes. Compared with the prior art, the beneficial effects of the computer device provided in this application are the same as those of the lightweight secure communication method for power systems provided in the above embodiments, and other technical features in the electronic device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0156] A preferred embodiment of this application also provides a storage medium including a stored program that, when the program is executed, controls the device where the storage medium is located to perform the steps of the lightweight secure communication method for power systems described in the above embodiments.

[0157] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0158] If the functions described in this embodiment are implemented as software functional units and sold or used as independent products, they can be stored in one or more computing device-readable storage media. Based on this understanding, the parts of this application's embodiments that contribute to the prior art or the technical solutions can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a computing device (which may be a personal computer, server, mobile computing device, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage media include: USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, optical disks, and other media capable of storing program code.

[0159] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code. The solutions in the embodiments of this application can be implemented in various computer languages, such as the object-oriented programming language C++ and the embedded programming language C.

[0160] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0161] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0162] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0163] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the lightweight secure communication method for power systems as described above.

[0164] The computer program product provided in this application can solve the technical problems of insufficient security, poor adaptability, and poor robustness in existing power communication solutions. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the lightweight secure communication method for power systems provided in the above embodiments, and will not be repeated here.

[0165] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0166] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A lightweight secure communication method for power systems, characterized in that, Including the following steps: Restricted terminals apply for certificateless key materials from the key center by introducing a time window and a one-time random number, and the materials are then distributed to the restricted terminals. Lightweight hash-based message authentication code HMAC is used for integrity verification to realize the application for certificateless keys. The key center and the restricted terminal each use a short-term private key to generate a local private key for the restricted terminal, and trigger a private key update and discard the old session key when the restricted terminal period epoch switches or an anomaly occurs. The restricted terminal generates an intermediate public key based on the accompanying public key, adds the intermediate public key to the accompanying public key to generate the restricted terminal public key, and establishes a certificateless trust chain by combining the restricted terminal's local private key for signature verification. Based on the session key calculated between communication-restricted terminals using their own private key and the other party's public key, and the identity identifiers of both parties as inputs to the key derivation function KDF, a multi-purpose key for encryption, message authentication, and encryption block derivation is derived to achieve lightweight session key negotiation. A hierarchical queuing, block aging, and CPU / power-aware production rate control strategy is adopted to divide the cache into high-priority and low-priority queues, and dynamically adjust the pre-encrypted packet generation rate according to CPU load and power level. When a restricted terminal detects a risk of key material leakage, it monitors the cryptographic calculation error rate, identifies abnormal communication patterns, receives security alarms from the key center, or triggers physical anti-tampering sensors; and when a risk is detected, it triggers an emergency key rotation process in coordination with the key center.

2. The lightweight secure communication method for power systems according to claim 1, characterized in that, Restricted terminals request certificate-free key materials from the key center by introducing a time window and a one-time random number, and the materials are then distributed to the restricted terminals. Lightweight hash-based message authentication code (HMAC) is used for integrity verification to achieve certificate-free key request. The specific steps include: Restricted terminal generates one-time random numbers Then, combined with their own identity markers and the current time window Calculate the hash value: ; Restricted terminals use hash values Using the public key matrix as an index, a temporary public key is generated by combining elements from the public key matrix. ; Restricted terminal generates temporary session key Using a temporary public key Encrypt and attach a lightweight HMAC tag: ; Restricted terminal sends encrypted data packets To the key center; Key Center Verification Time Window and After validation, generate using the same indexing method. And decrypt ,check ; The key center uses temporary session keys. The key material is encrypted and then sent to restricted terminals.

3. The lightweight secure communication method for power systems according to claim 2, characterized in that, The key center maintains a sliding time window of length L and stores the most recent M one-time random numbers. To achieve deduplication, during decryption, the same indexing function as that used by restricted terminals is employed to select m public key elements from the public key matrix and generate a temporary public key using elliptic curve point addition. Among them, P1, P2...P m These represent the elliptic curve points at the corresponding index positions in the selected public key matrix.

4. The lightweight secure communication method for power systems according to claim 2, characterized in that, The key center and the restricted terminal each use a short-term private key to generate a local private key for the restricted terminal. When the restricted terminal's epoch changes or an anomaly occurs, the private key is updated and the old session key is discarded. The specific steps include: The key center and restricted terminals exchange short-term random public keys on an epoch-period basis. Add a public key to generate an accompanying key. ; The key center obtains the index value based on the restricted terminal identifier. Then, a set of private key elements is selected from the private key matrix and combined to obtain the intermediate private key. ; The key center and restricted terminals each use short-term private keys. To generate the final private key, the key center first calculates the private key. It is then sent to the restricted terminal, which then calculates its local private key. ; When a restricted terminal detects an epoch switch or an anomaly, it immediately discards / overwrites the relevant session key locally and reports to the key center, triggering a private key update and discarding the old session key.

5. The lightweight secure communication method for power systems according to claim 4, characterized in that, The restricted terminal generates an intermediate public key based on the accompanying public key, adds the intermediate public key to the accompanying public key to generate the restricted terminal's public key, and uses this public key to sign and verify the signature, establishing a certificateless trust chain. The specific steps include: Restricted terminals based on accompanying public key With identity markers Indexing public key matrix elements, dot-matrix addition generates intermediate public key. ; Restricted terminals will use the intermediate public key With accompanying public key Get the restricted terminal public key by clicking. ; Restricted terminals use local private keys For including time windows and SMS Generate signature To provide proof of consistency; Communication peer receives and After verifying consistency, a certificate-free trust chain is established.

6. The lightweight secure communication method for power systems according to claim 5, characterized in that, Based on the session key calculated between the communication-restricted terminals using their own private key and the other party's public key, and the identity identifiers of both parties as inputs to the key derivation function KDF, a multi-purpose key for encryption, message authentication, and encrypted block derivation is derived to achieve lightweight session key negotiation. The specific steps include: Both communicating parties, A and B, calculate each other's public key locally. , ; Each entity collaborates with a key center to calculate its own private key. , ; The session key is calculated by multiplying the user's private key by the other party's public key. Restricted terminal A then calculates the session key. Restricted terminal B calculates the session key ; The communicating parties use the obtained session key and their respective identity identifiers as inputs to the KDF to derive a multi-purpose key for encryption, message authentication, and encryption block derivation. The key material includes: the current epoch value, the accompanying public key R, and the identity identifiers (IDs) of the communicating parties A and B. A ID B The KDF uses an HKDF or an equivalent HMAC-based key derivation function.

7. The lightweight secure communication method for power systems according to claim 6, characterized in that, A production rate control strategy employing hierarchical queuing, block aging, and CPU / power awareness is adopted. The cache is divided into high-priority and low-priority queues, and the specific calculation formula for dynamically adjusting the pre-encrypted packet generation rate based on CPU load and power level is as follows: ； Where, clamp is the truncation function; battery_level represents the terminal's battery level, CPU_load represents the terminal's current CPU load, α is the CPU load threshold, β is the battery level threshold, k1 is the CPU load weight, k2 is the battery level weight, R_min is the minimum cache generation rate, R_base is the base cache generation rate, and R_max is the maximum cache generation rate.

8. The lightweight secure communication method for power systems according to claim 7, characterized in that, Upon detection of a risk, an emergency key rotation process is triggered in collaboration with the key center, which includes the following steps: The key center synchronizes emergency status with restricted terminals and invalidates key materials related to the affected epoch; Based on the newly generated accompanying public key, the next-generation key is recalculated using restricted terminal private key generation, restricted terminal public key generation, and the minimum update key material issued by the key center. Automatically identify encrypted blocks in the cache that are associated with the affected epoch or key identifier, and securely reclaim them by overwriting data; Generate audit credentials and transmit them to the key center.

9. A lightweight secure communication device for a power system, characterized in that, include: The certificateless key application module is used by restricted terminals to apply for certificateless key materials from the key center by introducing a time window and a one-time random number and then distribute them to the restricted terminals. Lightweight hash-based message authentication code HMAC is used for integrity verification to realize the certificateless key application. The restricted terminal private key generation module is used by the key center and the restricted terminal to generate local private keys for the restricted terminal using short-term private keys, and to trigger private key updates and discard old session keys when the restricted terminal epoch switches or an abnormality occurs. The restricted terminal public key generation module is used to generate an intermediate public key based on the accompanying public key of the restricted terminal, add the intermediate public key and the accompanying public key to generate the restricted terminal public key, and combine it with the local private key of the restricted terminal to sign and verify to establish a certificateless trust chain. The lightweight session key negotiation module is used to derive a multi-purpose key for encryption, message authentication and encryption block derivation based on the session key calculated between communication-restricted terminals using their own private key and the other party's public key, and the identity identifiers of both parties as inputs to the key derivation function KDF, thereby realizing lightweight session key negotiation. The encrypted block cache module is used to divide the cache into high-priority and low-priority queues using a hierarchical queue, block aging and CPU / power-aware production rate control strategy, and dynamically adjust the pre-encrypted packet generation rate according to CPU load and power level. The collaborative leakage response and security recycling module is used to monitor the cryptographic calculation error rate, identify abnormal communication patterns, receive security alarms from the key center, or trigger physical anti-tamper sensors when a restricted terminal detects the risk of key material leakage; and triggers an emergency key rotation process in collaboration with the key center when a risk is detected.

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

11. A storage medium comprising a stored program, characterized in that, When the program is running, it controls the device containing the storage medium to perform the steps of the lightweight secure communication method for power systems as described in any one of claims 1 to 8.

Images