Hydropower station SCADA system communication method based on lightweight encryption

Abstract

The invention provides a hydropower station SCADA system communication method and device based on lightweight encryption, and the method comprises the steps: inserting an encryption layer in a Modbus / TCP protocol stack, carrying out the AES-128-CTR encryption of a function code and a data field of a message, and keeping a protocol header as a plaintext, so as to guarantee the equipment compatibility; the encryption layer dynamically generates a counter based on a device unique identifier and a timestamp, a key management center generates a root key by using a physical unclonable function, generates a 128-bit AES key through a key derivation function, and realizes low-overhead key broadcast in combination with an improved MQTT-SN protocol; when key synchronization fails, the system may roll back to a historical key and initiate a temporary session key agreement mechanism. Through combination of software encryption proxy and hardware acceleration optimization, communication security enhancement is realized, meanwhile, the requirements of low delay, low resource occupation and high availability are met, and the method can be widely applied to security communication scenes of hydropower stations and other industrial control systems.

Description

TECHNICAL FIELD

[0001] The application relates to the technical field of industrial control system communication security, and in particular to a hydropower station SCADA system communication method and device based on lightweight encryption. BACKGROUND

[0002] As the core communication architecture of industrial control systems, SCADA systems are widely used in remote monitoring and data acquisition of critical infrastructures such as hydropower stations. In related technologies, a basic industrial communication system is constructed through the collaborative work of Modbus / TCP protocol, IPSec encryption mechanism and traditional hardware security modules. Specifically, this system covers the whole process from data acquisition, transmission to control instruction issuing, including protocol analysis, encryption processing, key management and other key links. With the development of industrial Internet of Things (IIoT) and edge computing, SCADA systems gradually evolve towards intelligence and networking, but their communication security still relies on early designs, lacking systematic defense capabilities against modern network attacks.

[0003] However, in the existing SCADA communication method, Modbus / TCP protocol is directly used for plaintext transmission without built-in encryption mechanism, which may lead to tampering or replay attacks of control instructions. In addition, traditional IPSec or national standard SM4 encryption schemes usually rely on special encryption chips, which are expensive to modify and difficult to adapt to old devices, and their encryption delay generally exceeds 5ms, which cannot meet the strict requirements of hydropower stations for real-time control. Due to the lack of dynamic key management and hybrid communication compatible mechanisms, the existing system is difficult to recover after key leakage, and in the scenario of coexistence of new and old devices, it is easy to cause communication interruption, thereby affecting the stability and security of the system. SUMMARY

[0004] The present application aims to at least partially solve one of the technical problems in the related art.

[0005] To this end, the first object of the present application is to propose a hydropower station SCADA system communication method based on lightweight encryption.

[0006] The second object of the present application is to propose a hydropower station SCADA system communication device based on lightweight encryption.

[0007] The third object of the present application is to propose an electronic device.

[0008] The fourth object of the present application is to propose a computer-readable storage medium.

[0009] The fifth object of the present application is to propose a computer program product.

[0010] To achieve the above object, the first aspect of the present application proposes a kind of communication method of hydropower station SCADA system based on lightweight encryption, comprising:

[0011] Insert encryption layer between the application layer and the transport layer of Modbus / TCP protocol stack, the encryption layer is used to encrypt the function code and data field of Modbus message, and the transaction identification protocol header information is kept as plaintext;

[0012] In response to receiving Modbus / TCP data frame, the encryption layer separates the protocol header and data payload, and generates a counter based on the device unique identification and the current timestamp, the counter includes timestamp prefix and self-incrementing serial number, for key stream generation of AES-128-CTR encryption algorithm;

[0013] If the encryption identification bit of the data frame is 0x01, the data payload is encrypted using the dynamic counter, and the encrypted data payload is combined with the protocol header, encryption identification bit and CRC check code to generate encrypted message;

[0014] If the encryption identification bit of the data frame is 0x00 or the sender device ID is not in the preloaded encryption whitelist, the encryption layer enters transparent transmission mode, and directly transmits the original data frame;

[0015] The key management center generates a root key based on a physically unclonable function, and generates a 128-bit AES key through a key derivation function in combination with a device serial number and a timestamp;The key management center broadcasts the encrypted key through an improved MQTT-SN protocol, which supports message confirmation mechanism and binary compression to reduce key distribution overhead;

[0016] In response to key synchronization failure, if synchronization fails for three times in succession, load the last three groups of historical keys, and send alarm information to the operation and maintenance platform, while starting a temporary session key negotiation mechanism.

[0017] Optionally, the dynamic counter is generated in the following manner:

[0018] The first 64 bits are generated by the hash value of timestamp and device ID, wherein the timestamp is 32-bit Unix timestamp, and the device ID is 32-bit unique device code;

[0019] The last 64 bits are self-incrementing serial number, the initial value is 0, and it is reset to 0 after device restart.

[0020] Optionally, the key generation mechanism comprises:

[0021] SRAM PUF is used to generate physically unclonable root key;

[0022] In combination with the device serial number and the timestamp, a 128-bit AES key is generated by a key derivation function;

[0023] The key is updated once a day and is encrypted and stored by a hardware security module.

[0024] Optionally, the optimization of the MQTT-SN protocol comprises:

[0025] A message confirmation mechanism is supported, and retransmission is performed when no confirmation response is received;

[0026] A binary encoding method is used to compress the key distribution message, and the data volume of a single broadcast is less than 100 bytes;

[0027] Message buffering and retransmission in a device sleep state are supported.

[0028] Optionally, the triggering condition of the transparent transmission mode comprises:

[0029] The 7th byte of the received message is a 0x00 encrypted identification bit;

[0030] The sender device ID is not in a preloaded encryption whitelist.

[0031] To achieve the above purpose, a second aspect embodiment of the present application proposes a hydropower station SCADA system communication device based on lightweight encryption, comprising:

[0032] An encryption proxy gateway module is deployed on the remote terminal unit side and is connected with a Modbus / TCP protocol stack, and is used to receive and process Modbus / TCP data frames from PLC or other control devices;

[0033] A key management center module is deployed on the SCADA server side and is connected with the encryption proxy gateway module through the MQTT-SN protocol, and is used to generate a root key based on PUF and generate a 128-bit AES key through a key derivation function;

[0034] An exception handling module is connected with the encryption proxy gateway module, and is used to load the last three groups of historical keys when three consecutive key synchronization failures occur, and send alarm information to an operation and maintenance platform, and start a temporary session key negotiation mechanism.

[0035] Optionally, the encryption proxy gateway module comprises:

[0036] A data analysis submodule is used to separate the protocol header and the data payload of the Modbus / TCP data frame;

[0037] An encryption processing submodule generates a dynamic counter based on the device unique identifier and the timestamp in response to a request with an encryption identification bit of 0x01, and uses the AES-128-CTR algorithm to encrypt the data payload.

[0038] The decryption processing submodule, in response to receiving a downlink control instruction with an encryption identification bit of 0x01, generates a dynamic counter consistent with the encryption end based on the same device unique identification and timestamp, and performs an AES-128-CTR decryption operation;

[0039] The transparent transmission control submodule, in response to the encryption identification bit being 0x00 or the sender device ID not being in the encryption whitelist, automatically switches to a transparent transmission mode, and directly forwards original data frames bypassing the encryption layer.

[0040] Optionally, the key management center module loads the primary key and the backup key through a hardware security module, and when the primary key is updated, encrypts the new key using the old key to generate a KeyUpdate message, and broadcasts the KeyUpdate message to all devices through an MQTT-SN protocol.

[0041] To achieve the above purpose, a third aspect of the present application provides an electronic device, comprising: a processor, and a memory in communication connection with the processor;

[0042] The memory stores computer execution instructions;

[0043] The processor executes the computer execution instructions stored in the memory to implement the method according to any one of the first aspect.

[0044] To achieve the above purpose, a fourth aspect of the present application provides a computer readable storage medium, the computer readable storage medium stores computer execution instructions, and the computer execution instructions are executed by a processor to implement the method according to any one of the first aspect.

[0045] To achieve the above purpose, a fifth aspect of the present application provides a computer program product, the computer program is executed by a processor to implement the method according to any one of the first aspect.

[0046] The technical scheme provided by the embodiments of the present application at least brings the following beneficial effects:

[0047] 1. Significantly improve communication security: the present application adopts the AES-128-CTR mode to encrypt the function code and data field of the Modbus message, retains the protocol header plaintext transmission, and avoids device identification conflict. Combined with the PUF+HKDF key generation mechanism and the dynamic counter design, the system can resist common attack methods such as replay attack and man-in-the-middle attack, and after testing, the system can still normally synchronize the key under the environment of 20% packet loss rate, and the system availability reaches 99.99%.

[0048] 2. Zero hardware modification cost: The application realizes the encryption function in pure software form without replacing or adding special encryption chips. The single-node modification cost is less than 50 yuan, which is much lower than the traditional hardware encryption scheme (>2000 yuan). The system is compatible with Modbus / TCP devices produced after 1990, and supports multiple brands of PLCs such as Siemens S7-300 / 400 series, with good deployment adaptability.

[0049] 3. Meet real-time requirements: The encryption delay of the application under the ARM Cortex-A53 architecture is 1.8ms, which is much lower than the traditional SSL scheme (15.2ms), meeting the requirement of less than 5ms encryption delay for hydropower station control system. CTR mode avoids data padding, ensures the length of the message unchanged, and reduces the risk of network congestion. The CPU occupancy is less than 3%, and the memory occupancy is less than 5MB, which is suitable for old devices with limited resources.

[0050] 4. High compatibility and hybrid networking capability: The application supports transparent transmission mode, automatically identifies unencrypted devices and transmits data, and realizes hybrid networking of new and old devices. The white list mechanism uses [device ID (4B) | valid period (4B)] format to ensure the flexibility and security of device identity recognition and authorization management.

[0051] 5. Key management automation and high availability: The key update process of the application is automated, updated once a day, and broadcasted through MQTT-SN protocol, supporting rollback and alarm mechanism. In the case of key synchronization failure, the system can automatically load the last three sets of historical keys to prevent communication interruption. Long-term stability test shows that in high load scenarios (500 control instructions per second), the key synchronization success rate is as high as 99.98%, without loss of control instructions caused by encryption.

[0052] 6. Compliance with industrial safety standards and scalability: The design of the application complies with multiple industrial safety standards, with good compliance. The encryption layer structure supports smooth upgrade to other algorithms such as SM4, which only needs to replace the algorithm library, facilitating future technology evolution. The system architecture can also be copied to other industrial protocols (such as DNP3, IEC 104, etc.), with good scalability and universality.

[0053] In summary, the application effectively solves the technical problems of hydropower station SCADA system in communication security, modification cost, real-time performance, compatibility, etc. without replacing the existing hardware devices, with high security, low cost, low delay, high availability, strong compatibility, etc. It has good industrial application prospect and promotion value.

[0054] Additional aspects and advantages of the application will be in part apparent and in part pointed out hereinafter. Attached Figure Description

[0055] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein:

[0056] Figure 1 A flowchart illustrating a communication method for a hydropower station SCADA system based on lightweight encryption, provided in an embodiment of this application;

[0057] Figure 2 This is a schematic diagram of the architecture of a communication method for a hydropower station SCADA system based on lightweight encryption, provided in an embodiment of this application. Detailed Implementation

[0058] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0059] To address the problems existing in the prior art, this application provides a communication method for a hydropower station SCADA system based on lightweight encryption, including the following steps 101 to 106, which enhances system security through layered encryption, dynamic key management, protocol optimization and other technical means.

[0060] like Figure 1 As shown, the method includes the following steps:

[0061] Step 101: Insert an encryption layer between the application layer and the transport layer of the Modbus / TCP protocol stack. The encryption layer is used to encrypt the function code and data field of the Modbus message, while keeping the transaction identifier protocol header information in plaintext.

[0062] In this embodiment of the application, step 101 includes: inserting an encryption layer between the application layer and the transport layer of the Modbus / TCP protocol stack to perform layered encryption on the function code and data field in the Modbus message, while retaining the Modbus protocol header (including header information such as transaction identifier) ​​to be transmitted in plaintext, thereby ensuring compatibility with existing SCADA systems.

[0063] Specifically, the encryption layer in the embodiments of the present application is preferably implemented by using Python 3.8 and above versions, and is deployed as middleware architecture on the side of a remote terminal unit (RTU) or other gateway device. The encryption layer realizes transparent interception and protocol analysis of the message by listening to the Modbus / TCP default port 502, and performs encryption processing on the communication data without changing the original PLC or SCADA master station structure.

[0064] In the system initialization phase, the encryption layer loads the primary key and the backup key from a preset key storage path. If no key file is detected, a zero value is used as the default initial key to ensure that the system can be normally started. In the running process, the key management center generates and issues a new key at 00:00 every day according to a preset key update strategy. If key synchronization fails for three consecutive times, the key rollback mechanism is automatically triggered to load the latest available historical key to ensure the continuous availability and security of the data link.

[0065] To further improve the real-time performance of the encryption method in the embodiments of the present application under the embedded device or low-power ARM architecture, the embodiments of the present application can optionally combine the ARMNeon instruction set to perform instruction-level optimization on the AES-128-CTR algorithm. Through this optimization scheme, the single-frame encryption delay can be reduced from 8 ms to about 1.8 ms under a typical ARMv7 architecture, which meets the strict requirement of the hydropower station SCADA control instruction that the encryption delay should not exceed 5 ms.

[0066] In addition, in the embodiments of the present application, the Modbus / TCP client connection requests from multiple PLCs or sensors can be processed through multi-threading concurrency, which significantly improves the overall throughput capacity of the encryption layer and ensures the stability and real-time performance in a large-scale multi-node concurrent scenario.

[0067] In step 102, in response to receiving the Modbus / TCP data frame, the encryption layer separates the protocol header and the data payload, and dynamically generates a counter based on the device unique identifier and the current timestamp. The counter includes a timestamp prefix and an incremental serial number, which is used for key stream generation of the AES-128-CTR encryption algorithm.

[0068] In the embodiments of the present application, step 102 includes: when the encryption layer listens to and receives the Modbus / TCP data frame from the PLC or other field device, first, the data frame is parsed to separate the Modbus protocol header and the data payload part. The protocol header usually includes transaction identifier, protocol identifier, length field, unit identifier and other information, which is used to ensure the basic analyzability of the Modbus message, so in the present application, this part of content is transmitted in plaintext; and the function code and the subsequent data field are encrypted to ensure the confidentiality and integrity of the instructions and data.

[0069] After the separation is completed, the embodiment of the application generates a counter required for encryption based on the device unique identifier and the current timestamp. The counter is used for key stream generation of the AES-128-CTR encryption algorithm, and can ensure that the encryption key stream of each frame of data is unique within the same physical device and the same time period, thereby effectively resisting the risk of replay attacks and key stream reuse.

[0070] In the application, the specific generation mode of the dynamic counter is as follows:

[0071] The first 64 bits are generated by combining the current 32-bit Unix timestamp and the 32-bit device unique identifier (such as the device code of PLC or RTU), and then compressing the combination through a preset hash function, to obtain the prefix part of the counter;

[0072] The last 64 bits are a self-incrementing serial number, the initial value of which is 0, and it is incremented by 1 each time the Modbus data payload is successfully encrypted, to distinguish multiple messages within the same timestamp and prevent key stream reuse.

[0073] Therefore, the structure of the dynamic counter according to the embodiment of the application is [timestamp (4B) | device identifier (4B) | self-incrementing serial number (8B)], a total of 128 bits. The device unique identifier can be pre-allocated by the hydropower station device management system, such as the device code 0x1234ABCD of the gate controller, which can be used as the content of the field.

[0074] To ensure the security and unpredictability of the key stream under long-term operation, the device self-incrementing serial number is automatically reset to 0 when the device is restarted, and the timestamp field is cleared once a day at midnight, to avoid potential counter repetition after long-term continuous operation. Through the generation and management mechanism of the dynamic counter described above, the uniqueness control and security enhancement of the key stream of the AES-128-CTR encryption process can be achieved without increasing the complexity of additional hardware.

[0075] Step 103, if the encryption identifier bit of the data frame is 0x01, the dynamic counter is used to encrypt the data payload, and the encrypted data payload, the protocol header, the encryption identifier bit and the CRC check code are combined to generate an encrypted message;

[0076] In the embodiment of the application, step 103 includes: when the encryption layer detects that the encryption identifier bit of the Modbus / TCP data frame is 0x01, performing layered encryption processing on the data frame. Specifically, the embodiment only encrypts the function code and the data field in the Modbus message, and the protocol header information such as the transaction identifier is kept in plaintext, to ensure that the message can be normally identified and routed when passing through the existing hydropower station SCADA network.

[0077] In a specific operation, the encryption layer first separates the protocol header and the data payload of the Modbus message, wherein the protocol header usually includes a transaction identifier, a protocol identifier and length information, occupying the first 6 bytes, and the data payload to be encrypted starts from the 7th byte to the CRC check segment before the end of the message.

[0078] After the separation is completed, the embodiment of the application generates a counter based on the unique identifier of the current device and the current timestamp by the method described in step 102, which is used to drive the key stream generation of the AES-128-CTR mode. With the help of the dynamic counter, each frame of message can obtain a unique key stream related to time and device, which significantly improves the anti-replay attack capability and avoids the risk of key stream repetition and message forgery that may exist in the traditional fixed counter scheme.

[0079] Subsequently, the encryption layer uses the generated key stream to perform layered encryption processing on the extracted data payload, assembles the ciphertext and the original protocol header information after the processing is completed, inserts a flag bit (set to 0x01) indicating that the message has been encrypted at a fixed position, and finally calculates the CRC check code of the entire message to ensure the data transmission integrity and error detectability.

[0080] Compared with the prior art, the embodiment of the application has the following improvement effects: the device address or transaction identifier conflict problem that may be caused by the traditional full-link encryption scheme (such as IPSec VPN) is avoided, the mutual authentication and fast response of the SCADA system device are ensured, the dynamic counter based on the timestamp and the device identifier is introduced to effectively prevent the repetition of the counter and resist the occurrence of replay attacks, the pure software encryption scheme is adopted, no special encryption chip needs to be added, the single-node transformation cost can be greatly reduced to less than 50 yuan, and the cost is significantly lower than the high-cost mode of the traditional hardware encryption transformation.

[0081] It should be noted that, in order to ensure the synchronization accuracy of the timestamp part of the dynamic counter in a multi-device scenario, the embodiment of the application can optionally combine the network time protocol (NTP) to automatically synchronize the system time of the field device, so as to control the possible time drift within an acceptable range and ensure the consistency and reliability of the counter generation.

[0082] Step 104, if the encryption identifier bit of the data frame is 0x00 or the sender device ID is not in the preloaded encryption whitelist, the encryption layer enters the transparent transmission mode and directly transmits the original data frame.

[0083] In the embodiment of the present application, step 104 comprises: when the encryption layer detects that the encryption identification bit of the Modbus / TCP data frame is 0x00, or judges that the sender device ID is not included in the preloaded encryption whitelist, automatically switching to the transparent transmission mode, without performing any encryption or decryption processing on the received original data frame, and directly transmitting it to the subsequent transmission process.

[0084] Specifically, in the embodiment of the present application, the trigger condition of the transparent transmission mode includes at least one of the following two situations:

[0085] The encryption identification bit shown in the received Modbus message at a fixed position (7th byte) is 0x00, indicating that the message is an unencrypted message;

[0086] The sender device unique identifier (device ID) parsed from the message is not included in the system preloaded encryption whitelist, wherein the whitelist can be configured and dynamically managed in the data format of [device ID (4B) | validity period (4B)] to allow the operation and maintenance personnel to flexibly adjust the strategy of whether the device participates in the encryption communication.

[0087] When any of the above conditions is met, the encryption layer in the embodiment of the present application immediately skips the encryption / decryption processing logic after being recognized by the protocol analysis module, and passes the received original Modbus data frame to the SCADA system or the lower device as it is, avoiding unnecessary encryption and decryption calculation and additional processing delay, and ensuring that old devices, debugging devices or third-party temporary access devices that do not enable encryption function can work normally in the original network and are not affected.

[0088] By introducing the transparent transmission mode, the present application enhances the security of the SCADA network while taking into account the compatibility and progressive reconstruction needs of different generations of devices, and can flexibly switch whether to perform encryption processing on the communication according to the field situation, avoiding the additional performance burden and configuration complexity that may be caused by the one-size-fits-all mandatory encryption of the whole network.

[0089] In step 105, the key management center generates a root key based on a physically unclonable function, and generates a 128-bit AES key through a key derivation function combined with a device serial number and a timestamp; the key management center broadcasts the encrypted key through an improved MQTT-SN protocol, and the MQTT-SN protocol supports a message confirmation mechanism and binary compression to reduce the key distribution overhead.

[0090] In the embodiment of the present application, step 105 comprises: the key management center is responsible for providing unified and secure key generation and distribution services for each remote terminal unit (RTU) and encryption gateway in the entire hydropower station SCADA system. The key management center generates a root key based on a physical unclonable function (PUF), and generates a working key for AES-128-CTR encryption by combining a device serial number and a time stamp through a key derivation function (HKDF).

[0091] In a specific implementation, the key management center first calls the SRAM PUF technology to extract the physical characteristics exhibited by the hardware when starting up after power-on, and generates a physically unclonable root key, thereby ensuring that the key source is unique and difficult to be physically copied or counterfeited. Subsequently, by combining the unique serial number of each field device and the current time stamp information, the root key is derived twice through a key derivation function to generate a 128-bit AES key that has time effectiveness and device uniqueness. The derived key is updated once a day by default and is stored in a hardware security module (HSM), so as to ensure that the key also has credibility and tamper resistance during the local storage stage.

[0092] To ensure that the derived encryption key can be safely and efficiently synchronized to each RTU node, the present application optimizes the existing MQTT-SN protocol. Specifically, the following aspects are included:

[0093] Message confirmation mechanism: after each key broadcast, each terminal node is required to return a confirmation message (ACK) after successfully receiving and decrypting the key. If no confirmation response is received within a set time window (such as 30 seconds), the key distribution retransmission is automatically triggered, and a maximum of 3 repeated attempts are allowed, to ensure the reliability of key synchronization.

[0094] Binary compression transmission: the key distribution message is encoded in binary format, effectively compressing the data volume of a single broadcast to within 100 bytes, significantly reducing the occupation of network bandwidth, and adapting to remote sites in low-bandwidth scenarios.

[0095] Sleep device support: for low-power or intermittent online devices that may exist in the field, the MQTT-SN protocol supports caching key messages on the server side and completing automatic retransmission when the device is back online, avoiding key loss or security synchronization failure due to temporary offline nodes.

[0096] In the embodiment of the present application, the key distribution process generally includes that after the server side obtains the root key through the TPM chip and PUF, a new derived key is generated, the new key is encrypted and packaged using the currently valid old key, and then the new key is sent to all device nodes in the form of UDP broadcast through the optimized MQTT-SN protocol. After each device node receives the key, decryption and validity verification are completed, and the entire synchronization closed loop is completed by returning a confirmation message.

[0097] To further enhance the robustness and security of the system, the embodiment of the application also designs an exception handling mechanism: if the key synchronization fails for three consecutive times, the relevant RTU node will automatically load the last three sets of historical keys to avoid data link interruption, and at the same time send an alarm information (such as 0xE001) to the operation and maintenance platform to prompt manual intervention; on this basis, a new session key can also be quickly generated through a temporary session key negotiation mechanism (for example, based on the ECDH algorithm) to ensure that the system can continue to operate safely in extreme scenarios.

[0098] By adopting the PUF physical unclonable function technology, the layered key derivation mechanism based on the serial number and the timestamp, and the MQTT-SN broadcast distribution mode with the lightweight and message confirmation function, the embodiment of the application can effectively realize the dynamic update, secure transmission and efficient synchronization of the key in the SCADA system, significantly improve the security, controllability and adaptability of the key management, and at the same time, take into account the network load and the resource limitation of the field device, which is suitable for the industrial scene such as the hydropower station with high requirements for the control real-time performance and safety.

[0099] In order to realize the above-mentioned embodiment, the application further provides a hydropower station SCADA system communication device based on lightweight encryption. The device comprises: an encryption agent gateway module, which is deployed on the remote terminal unit side, connected with the Modbus / TCP protocol stack, and used for receiving and processing the Modbus / TCP data frame from the PLC or other control device;

[0100] a key management center module, which is deployed on the SCADA server side, connected with the encryption agent gateway module through the MQTT-SN protocol, and used for generating the root key based on the PUF, and generating the 128-bit AES key through the key derivation function;

[0101] an exception handling module, which is connected with the encryption agent gateway module, and used for loading the last three sets of historical keys when the key synchronization fails for three consecutive times, sending the alarm information to the operation and maintenance platform, and starting the temporary session key negotiation mechanism.

[0102] Optionally, the encryption agent gateway module comprises:

[0103] a data analysis submodule, which is used for separating the protocol header and the data payload of the Modbus / TCP data frame;

[0104] an encryption processing submodule, which generates a dynamic counter based on the device unique identifier and the timestamp in response to the request with the encryption identifier bit being 0x01, and encrypts the data payload using the AES-128-CTR algorithm;

[0105] The decryption processing submodule, in response to receiving a downlink control instruction with an encryption identification bit of 0x01, generates a dynamic counter consistent with the encryption end based on the same device unique identification and timestamp, and performs an AES-128-CTR decryption operation;

[0106] The transparent transmission control submodule, in response to the encryption identification bit being 0x00 or the sender device ID not being in the encryption whitelist, automatically switches to a transparent transmission mode, bypasses the encryption layer and directly forwards the original data frame.

[0107] Optionally, the key management center module loads the primary key and the backup key through a hardware security module, and when the primary key is updated, encrypts the new key using the old key to generate a KeyUpdate packet, and broadcasts the KeyUpdate packet to all devices through the MQTT-SN protocol.

[0108] As to the device in the above-mentioned embodiments, the specific manner in which each module performs operations has been described in detail in the embodiments related to the method, and will not be described in detail here.

[0109] In order to achieve the above-mentioned embodiments, the present application also proposes an electronic device, comprising: a processor, and a memory in communication connection with the processor; the memory stores computer execution instructions; the processor executes the computer execution instructions stored in the memory to realize the method provided by the foregoing embodiments.

[0110] In order to achieve the above-mentioned embodiments, the present application also proposes a computer readable storage medium, the computer readable storage medium stores computer execution instructions, and the computer execution instructions are executed by the processor to realize the method provided by the foregoing embodiments.

[0111] In order to achieve the above-mentioned embodiments, the present application also proposes a computer program product, comprising a computer program, which is executed by the processor to realize the method provided by the foregoing embodiments.

[0112] The collection, storage, use, processing, transmission, provision and disclosure of user personal information in the present application comply with relevant laws and regulations, and do not violate public order and good customs.

[0113] It should be noted that the personal information from the user should be collected for legal and reasonable purposes, and should not be shared or sold outside these legal uses. In addition, such collection / sharing should be carried out after obtaining the informed consent of the user, including but not limited to informing the user to read the user agreement / user notice before the user uses the function, and signing an agreement / authorization including authorization of relevant user information. In addition, any necessary steps should be taken to protect and safeguard access to such personal information data, and to ensure that other people with access to personal information data comply with their privacy policy and processes.

[0114] The application contemplates an implementation that provides users with the option to selectively block the use or access of personal information data. That is, the disclosure contemplates providing users with various options over the use of their personal information data, including the ability to prevent collection of such data. In addition, the disclosure contemplates providing users with control over who has access to their personal information data. For example, users can control access to their personal information data by providing or denying consent to the collection, recording, or use of their personal information data. In addition, users can control what types of personal information data are disclosed to others. For example, a user can control whether programs or services can access the user’s location data and can further control whether such programs or services can access the user’s location data to determine where the user is located, where the user has been, or where the user is going.

[0115] In the foregoing detailed description, reference is made to descriptive terms such as "one embodiment", "some embodiments", "an example", "a specific example" or "some examples" etc. for describing various embodiments or examples of the application. The descriptive terms are used for the convenience of the reader in understanding the application but are not intended to limit the application. Furthermore, the description of one certain feature, structure, material, or characteristic is not necessarily limited to that particular embodiment or example. In addition, different embodiments or examples described in the specification can be combined with each other, and the features described in different embodiments or examples can be combined with each other, unless they are explicitly mutually exclusive.

[0116] In addition, the terms "first", "second", etc. are used herein only to describe various embodiments or examples and are not intended to denote relative importance or imply that the indicated technical features are essential to the technical feature being described. Thus, a feature labeled "first", "second", etc. can explicitly or implicitly include at least one of the feature. In the description of the application, the meaning of "a plurality" is at least two, for example, two, three, etc., unless otherwise explicitly specified.

[0117] Any process or method described in a flowchart or otherwise described herein can be understood as representing code modules, segments, or portions of code that include one or more executable instructions for implementing specific logic functions (or steps) of the process, and the various embodiments of the application can include additional or fewer functions (or steps) than those shown or discussed, and the functions (or steps) can be performed in an order other than those described, including substantially concurrently or in reverse order, depending on the functionality involved. Thus, the order of the functions (or steps) is not necessarily limiting, and the functions (or steps) can be performed in any order or substantially concurrently.

[0118] The logic and / or steps represented in the flowcharts and / or described herein, for example, can be considered as a sequence of executable instructions stored in a computer readable medium, which can be executed by an instruction execution system, apparatus or device, such as a computer-based system, a processor-based system, or other system that can fetch the instructions from the instruction execution system, apparatus or device and execute the instructions, or a combination of them. For the purposes of this specification, a "computer readable medium" can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus or device. The computer readable medium can be a computer readable storage medium or a computer readable signal medium. The computer readable storage medium can include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, a portable computer diskette (magnetic), a RAM (random access memory), a ROM (read only memory), an EPROM (erasable programmable ROM), EEPROM (electrically erasable programmable ROM), a storage

[0119] It should be understood that portions of the application can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in a memory and executed by a suitable instruction execution system. As such, if implemented in hardware and in another embodiment, any of the following technologies, known in the art, or their combinations can be used: discrete logic circuitry having logic gates for implementing logic functions on data signals, application specific integrated circuits having appropriate combinational logic gates, programmable gate arrays (PGA), field programmable gate arrays (FPGA), and the like.

[0120] Those of ordinary skill in the art can understand that all or part of the steps carried out by the above-mentioned embodiment methods can be completed by programs instructing relevant hardware, and the programs can be stored in a computer readable storage medium. When the programs are executed, they include one of the steps of the method embodiments or a combination thereof.

[0121] In addition, each of the function units in each embodiment of the present application can be integrated in one processing module, or each unit can be physically present separately, or two or more units can be integrated in one module. The integrated module can be realized in the form of hardware or in the form of a software function module. When the integrated module is realized in the form of a software function module and sold or used as an independent product, it can also be stored in a computer readable storage medium.

[0122] The storage medium mentioned above can be a read-only memory, a magnetic disk or an optical disk, etc. Although the embodiments of the present application have been shown and described above, it should be understood that the above embodiments are exemplary and should not be construed as limiting the present application, and those skilled in the art can make changes, modifications, replacements and variations to the above embodiments within the scope of the present application.

[0123] It should be understood that the various forms of flow shown above can be reordered, added or deleted steps. For example, each step described in the present application can be executed in parallel, sequentially or in different order, as long as the desired results of the technical solutions of the present application can be achieved, which is not limited herein.

[0124] The above detailed description does not constitute a limitation on the scope of protection of the present application. Those skilled in the art should understand that various modifications, combinations, sub-combinations and replacements can be made according to design requirements and other factors. Any modifications, equivalent replacements and improvements within the spirit and principles of the present application should be included in the scope of protection of the present application.

Claims

1. A method for communication of a hydropower SCADA system based on lightweight encryption, characterized in that, The method comprises the following steps: An encryption layer is inserted between the application layer and the transport layer of the Modbus / TCP protocol stack, and the encryption layer is used for encrypting the function code and the data field of the Modbus message and leaving the transaction identification protocol header information as plaintext; In response to receiving a Modbus / TCP data frame, the encryption layer separates the protocol header from the data payload and dynamically generates a counter based on the device unique identification and the current timestamp, the counter comprising a timestamp prefix and an incremental serial number, for key stream generation of the AES-128-CTR encryption algorithm; If the encryption identification bit of the data frame is 0x01, the data payload is encrypted using the dynamic counter, and the encrypted data payload is combined with the protocol header, the encryption identification bit and the CRC check code to generate an encrypted message; If the encryption identification bit of the data frame is 0x00 or the sender device ID is not in the preloaded encryption whitelist, the encryption layer enters a transparent transmission mode and directly transmits the original data frame; A key management center generates a root key based on a physically unclonable function and generates a 128-bit AES key through a key derivation function in combination with the device serial number and the timestamp; The key management center broadcasts the encrypted key through an improved MQTT-SN protocol, and the MQTT-SN protocol supports a message confirmation mechanism and binary compression to reduce the key distribution overhead; If the key synchronization fails for three times in succession, the last three groups of historical keys are loaded, alarm information is sent to an operation and maintenance platform, and a temporary session key negotiation mechanism is started.

2. The method of claim 1, wherein, The dynamic counter is generated in the following manner: The first 64 bits are generated from the timestamp and the hash value of the device ID, wherein the timestamp is a 32-bit Unix timestamp and the device ID is a 32-bit unique device code; The last 64 bits are an incremental serial number, the initial value of which is 0 and which is incremented by 1 each time of encryption and reset to 0 after the device is restarted.

3. The method of claim 1, wherein, The key generation mechanism comprises: A physically unclonable root key is generated using an SRAM PUF; A 128-bit AES key is generated through a key derivation function in combination with the device serial number and the timestamp; The key is updated once a day and is encrypted and stored by a hardware security module.

4. The method of claim 1, wherein, The optimization of the MQTT-SN protocol comprises: A message confirmation mechanism is supported, and retransmission is performed when no confirmation response is received; A binary encoding method is used to compress the key distribution message, and the data volume of a single broadcast is less than 100 bytes; Message buffering and retransmission in a device sleep state are supported.

5. The method of claim 1, wherein, The triggering conditions of the transparent transmission mode comprise: The encryption identification bit of the received message is 0x00; The sender device ID is not in the preloaded encryption whitelist.

6. A hydropower SCADA system communication device based on lightweight cryptography, characterized in that, The method comprises: An encryption agent gateway module is deployed on the remote terminal unit side, connected with the Modbus / TCP protocol stack, and used for receiving and processing Modbus / TCP data frames from PLCs or other control devices; An encryption agent gateway module is deployed on the remote terminal unit side, connected with the Modbus / TCP protocol stack, and used for receiving and processing Modbus / TCP data frames from PLCs or other control devices; A key management center module is deployed on the SCADA server side and connected with the encryption proxy gateway module through the MQTT-SN protocol, used to generate a root key based on the PUF and generate a 128-bit AES key through a key derivation function; An exception processing module is connected with the encryption proxy gateway module, used to load the last three sets of historical keys when three consecutive key synchronization failures occur, send alarm information to the operation and maintenance platform, and start a temporary session key negotiation mechanism.

7. The apparatus of claim 6, wherein, The encryption proxy gateway module comprises: A data analysis submodule is used to separate the protocol header and data payload of the Modbus / TCP data frame; An encryption processing submodule is used to generate a dynamic counter based on the device unique identifier and the timestamp in response to a request with the encryption identifier bit being 0x01, and encrypt the data payload using the AES-128-CTR algorithm; A decryption processing submodule is used to generate a dynamic counter consistent with the encryption end based on the same device unique identifier and the timestamp in response to receiving a downlink control instruction with the encryption identifier bit being 0x01, and perform an AES-128-CTR decryption operation; A transparent transmission control submodule is used to automatically switch to the transparent transmission mode and bypass the encryption layer to directly forward the original data frame in response to the encryption identifier bit being 0x00 or the sender device ID not being in the encryption whitelist.

8. The apparatus of claim 6, wherein, The key management center module loads the primary key and the backup key through the hardware security module, and generates a KeyUpdate packet by encrypting the new key using the old key when the primary key is updated, and broadcasts the KeyUpdate packet to all devices through the MQTT-SN protocol.

9. An electronic device, comprising: It comprises: A processor and a memory connected with the processor in communication; The memory stores computer execution instructions; The processor executes the computer execution instructions stored in the memory to implement the method of any one of claims 1-5.

10. A computer-readable storage medium, characterized in that, The computer readable storage medium stores computer execution instructions, and the computer execution instructions are executed by the processor to implement the method of any one of claims 1-5.

Images