A two-way authentication and encrypted communication method based on HART-IP protocol

Abstract

This invention provides a two-way authentication and encrypted communication method based on the HART-IP protocol, comprising the following steps: S1: Deploying the IP addresses and corresponding public and private key data of the control device and the field device respectively to the control device and the field device using a configuration tool; S2: The control device sends an authentication request command to the field device, the field device parses and verifies the authentication request command, and sends an authentication request response back to the control device, the control device parses and verifies the authentication request response, and sends an authentication feedback command to the field device again; S3: The control device encrypts the session key and sends a session key distribution command to the field device, the field device parses and verifies the session key distribution command, and decrypts it to obtain the session key; S4: The control device and the field device perform encryption and decryption operations on the sent and received message data based on the session key to realize encrypted communication between the control device and the field device.

Description

Technical Field

[0001] This invention belongs to the field of device communication technology, and in particular relates to a two-way authentication and encrypted communication method based on the HART-IP protocol. Background Technology

[0002] HART-IP (Highway Addressable Remote Transducer over Internet Protocol) is a communication protocol that combines the traditional HART protocol with modern IP network technology. HART-IP allows HART devices to communicate over Ethernet networks, providing higher data transmission rates and more flexible network integration capabilities. Therefore, it is used to achieve high-speed, reliable communication between process automation equipment and control systems. As a standard Ethernet communication protocol, HART-IP has been widely used in the process automation industry, meeting the rapidly growing demands of industrial data transmission. Its low cost, high reliability, and strong compatibility have made it increasingly popular.

[0003] However, with the rapid development of industrial automation, intelligentization, the Internet of Things, and edge computing technologies, the industrial control system (ICS) field has entered a new stage of development. ICS are increasingly interconnecting with numerous external network devices. As a plaintext transmission protocol, HART-IP presents increasingly serious information security challenges. Currently, the HART-IP protocol is only designed to meet the communication, diagnostic, and control functions of ICS, without sufficient emphasis on protocol security. The lack of necessary protective measures allows attackers to exploit these vulnerabilities to damage ICS, causing incalculable losses.

[0004] Although there are existing research and experiments on information security of communication protocols in the industrial control field, the following problems still exist under current technology:

[0005] (1) Most mainstream industrial control systems check the compliance of the protocol, that is, the two parties in communication make a compliance judgment on the specific content of the HART-IP protocol. However, this does not solve the problem that the data is transmitted in plaintext, and the data still faces the risk of being stolen and tampered with.

[0006] (2) Some industrial control systems use private security protocols, such as pre-configuring session keys for encrypting communication data. Although this method ensures the confidentiality of the communication data between the two parties, it cannot perform identity authentication or authorization, and cannot determine whether the identities of the two parties are legitimate.

[0007] (3) Although the existing TLS or DTLS protocols can theoretically be used for HART-IP protocols, in industrial control scenarios, the resources of control devices are very limited and the industrial control system has extremely high requirements for real-time performance, so it is impossible to maintain the high communication overhead of TLS or DTLS. Summary of the Invention

[0008] This invention provides a two-way authentication and encrypted communication method based on the HART-IP protocol to solve the technical problems of poor confidentiality, lack of two-way authentication function, and high system resource requirements of conventional communication methods in the industrial control field under the existing technology.

[0009] To address the above problems, the technical solution of this invention is: a two-way authentication and encrypted communication method based on the HART-IP protocol, comprising the following steps:

[0010] S1: Deploy the IP addresses and corresponding public and private key data of the control device and the field device respectively to the control device and the field device using a configuration tool;

[0011] S2: The control device sends an authentication request command to the field device based on the HART-IP protocol. The field device parses and verifies the authentication request command and sends an authentication request response back to the control device. The control device parses and verifies the authentication request response and sends an authentication feedback command to the field device again, thereby realizing two-way identity authentication between the control device and the field device.

[0012] S3: After encrypting the session key, the control device sends a session key distribution command to the field device based on the HART-IP protocol. The field device parses and verifies the session key distribution command and decrypts it to obtain the session key.

[0013] S4: The control device and the field device respectively perform encryption and decryption operations on the sent and received message data based on the session key to realize encrypted communication between the control device and the field device.

[0014] Preferably, deploying IP addresses and public / private key data for the control device and the field device in S1 specifically includes the following steps:

[0015] S11: The IP address and corresponding public and private key data of the control device are deployed to the control device through a configuration tool, wherein the private key data is deployed in the HSM hardware security module of the control device;

[0016] S12: Deploy the IP address and corresponding public key data of the field device to the control device using a configuration tool;

[0017] S13: Configure the IP address of the valid field device to the control device using the configuration tool;

[0018] S14: Deploy the IP address and corresponding public and private key data of the field device to the field device through the configuration tool, wherein the private key data is deployed in the HSM hardware security module of the field device;

[0019] S15: Deploy the IP address and corresponding public key data of the control device to the field device using a configuration tool.

[0020] Preferably, the IP addresses and corresponding public and private key data of the control device and the field device are stored and entered in PEM text format.

[0021] Preferably, in step S2, the control device sends an authentication request command to the field device, specifically including the following steps:

[0022] S21: The control device uses its own private key to perform an encrypted signature calculation on the hexadecimal number of the last two bytes of its own IP address, and the constructed data part will carry the authentication request command of the control device's signature data.

[0023] Preferably, in step S2, the field device parses and verifies the authentication request command and sends an authentication request response back to the control device, specifically including the following steps:

[0024] S22: The field device uses the public key corresponding to the IP address of the control device to verify the signature data of the control device, and obtains the field device signature verification data;

[0025] S23: Compare the value of the field device's signature verification data with the last two bytes of the control device's IP address. If they are the same, the field device successfully authenticates the control device, and the field device uses its own private key to perform an encrypted signature calculation on the hexadecimal number of the last two bytes of its own IP address. The constructed data part will carry the authentication request response with the field device's signature data. If they are different, the field device fails to authenticate the control device.

[0026] Preferably, in S2, the control device parses and verifies the authentication request response and sends the authentication feedback command to the field device again, specifically including the following steps:

[0027] S24: The control device uses the public key corresponding to the IP address of the field device to verify the signature data of the field device, and obtains the control device signature verification data;

[0028] S25: Compare the value of the verification data of the control device with the last two bytes of the IP address of the field device. If they are the same, the control device successfully authenticates the field device and sends an authentication feedback command to the field device again. If they are different, the control device fails to authenticate the field device.

[0029] Preferably, in step S3, the control device encrypts the session key and sends a session key distribution command to the field device, specifically including the following steps:

[0030] S31: The control device uses the HSM module to generate a 16-byte session key required for the symmetric encryption algorithm;

[0031] S32: The control device uses the public key of the field device with which it communicates to encrypt the session key, and performs a hash calculation on the encrypted session key data to obtain the encrypted session key hash value;

[0032] S33: The control device uses its own private key to sign the encrypted session key hash value and constructs a session key distribution command whose data part carries the encrypted session key and the encrypted session key hash value signature data.

[0033] Preferably, in step S3, the field device parses and verifies the session key distribution command, and decrypts it to obtain the session key, specifically including the following steps:

[0034] S34: The field device uses the public key of the control device with which it communicates to verify the signature data of the encrypted session key hash value. If the verification is successful, the field device further uses its own private key to decrypt the encrypted session key to obtain the session key. If the verification fails, the task of distributing and exchanging the session key with the field device by the control device fails.

[0035] Preferably, the session key update cycle is 24 hours. When the session key update cycle expires, the control device updates the session key and re-performs the session key encryption and distribution task.

[0036] Preferably, in S4, the control device and the field device respectively perform encryption and decryption operations on the sent and received message data based on the session key, specifically including the following steps:

[0037] S41: The control device performs a hash calculation on the request data in the message data to be sent to obtain the hash value of the first request data;

[0038] S42: The control device uses a symmetric encryption algorithm to encrypt the message data to be sent, and the encryption key is the session key. The control device then sends the encrypted message data to the field device.

[0039] S43: The field device receives the encrypted message data and uses the session key to decrypt the encrypted message data. It performs a hash calculation on the request data in the decrypted message to obtain a second request data hash value. It compares the first request data hash value with the second request data hash value. If they are the same, the message data is available and the field device responds to the control device. If they are different, the message data is unavailable and the field device does not respond to the control device.

[0040] S44: The field device performs a hash calculation on the request data in the message data to be sent to obtain the hash value of the third request data;

[0041] S45: The field device uses a symmetric encryption algorithm to encrypt the message data to be sent, and the encryption key is the session key. The field device then sends the encrypted message data to the control device.

[0042] S46: The control device receives the encrypted message data and decrypts the encrypted message data using the session key. It performs a hash calculation on the request data in the decrypted message to obtain a fourth request data hash value. It compares the third request data hash value with the fourth request data hash value. If they are the same, the message data is available and the control device responds to the field device. If they are different, the message data is unavailable and the control device does not respond to the field device.

[0043] S47: Repeat steps S41-S46 until the communication task between the control device and the field device ends.

[0044] Because the present invention adopts the above technical solution, it has the following advantages and positive effects compared with the prior art:

[0045] This invention provides a two-way authentication and encrypted communication method based on the HART-IP protocol. Building upon the HART-IP protocol, it achieves two-way authentication and encrypted data communication between control devices and field devices through customized HART-IP command codes. A hash algorithm is employed to ensure communication integrity, addressing the vulnerabilities of plaintext data transmission in the HART-IP protocol, which is susceptible to theft, tampering, and man-in-the-middle attacks, thus enhancing data security and reliability during communication. Furthermore, this invention designs a more secure and lightweight encryption method based on the existing HART-IP protocol. Without consuming excessive industrial control equipment resources or affecting the real-time performance of the industrial control system, it ensures the confidentiality and integrity of communication, significantly reducing the resource consumption and requirements of control devices and field devices during communication. Attached Figure Description

[0046] Figure 1 A flowchart illustrating the bidirectional authentication and encrypted communication method based on the HART-IP protocol provided by this invention;

[0047] Figure 2 A schematic diagram illustrating the data configuration process between the control device and field devices provided by this invention;

[0048] Figure 3 The present invention provides a bidirectional authentication communication message flow model diagram based on the HART-IP protocol;

[0049] Figure 4 The present invention provides a key security distribution communication message flow model diagram based on the HART-IP protocol;

[0050] Figure 5 The present invention provides a model diagram of encrypted communication and communication integrity message flow based on the HART-IP protocol. Detailed Implementation

[0051] The following detailed description, in conjunction with the accompanying drawings and specific embodiments, provides a further detailed explanation of the bidirectional authentication and encrypted communication method based on the HART-IP protocol proposed in this invention. The advantages and features of this invention will become clearer from the following description and claims.

[0052] See Figures 1 to 5 This embodiment provides a two-way authentication and encrypted communication method based on the HART-IP protocol to improve the security and reliability of two-way communication between control devices and field devices in the industrial control field.

[0053] First, it should be noted that the control device mentioned in this embodiment refers to an electronic or electrical device used in an industrial control system to manage, regulate, and command field equipment. The control device is connected to the field equipment, can issue commands to the field equipment and read the response data from the field equipment, and further transmit the data to the control system for processing, thereby achieving automated control of the overall tooling. In this embodiment, the control device is the initiator of the communication process, i.e., the master in master-slave communication. The field equipment refers to the back-end equipment in the industrial control system, used to convert the commands of the control system into physical actions. It directly affects the physical motion process, achieving the control objective by adjusting or moving mechanical components, such as instruments and valves. In this embodiment, the field equipment is the responder of the communication process, i.e., the slave in master-slave communication.

[0054] This embodiment provides a two-way authentication and encrypted communication method based on the HART-IP protocol, which includes the following steps:

[0055] S1: Before establishing a secure HART-IP communication connection, the IP addresses and corresponding public and private key data of the control device and the field device are deployed to the control device and the field device respectively through the configuration tool to realize the data configuration of the control device and the field device;

[0056] S2: The control device sends an authentication request command to the field device based on the HART-IP protocol. The field device parses and verifies the authentication request command and sends an authentication request response back to the control device. The control device parses and verifies the authentication request response and sends an authentication feedback command to the field device again, thereby realizing two-way authentication between the control device and the field device.

[0057] S3: After two-way authentication is successful, the control device establishes a session key, encrypts the session key, and sends a session key distribution command to the field device based on the HART-IP protocol. The field device parses and verifies the session key distribution command, decrypts it to obtain the session key, and thus establishes a secure communication connection between the control device and the field device based on the session key.

[0058] S4: The control device and the field device respectively perform encryption and decryption operations on the sent and received message data based on the session key to realize encrypted communication between the control device and the field device.

[0059] See Figure 2 In a preferred embodiment, deploying IP addresses and public / private key data for the control device and field devices in S1 specifically includes the following steps:

[0060] S11: Deploy the IP address and corresponding public and private key data of the control device to the control device through the configuration tool.

[0061] In this embodiment, the configuration tool is a software tool that can configure and persistently store information such as IP address and asymmetric key into the configured device. Furthermore, because the configuration tool is used, in the event of key data leakage, a new key can be written using the configuration tool to ensure device availability and communication confidentiality.

[0062] The encryption algorithms used in this embodiment include RSA (which will be used as an example in the following description), elliptic curve cryptography, or other asymmetric encryption algorithms. RSA is an asymmetric encryption algorithm whose security relies on the difficult problem of prime factorization of large integers. It is widely used for data encryption and digital signatures. RSA uses a pair of keys, called a public key and a private key. The public key is used to encrypt data, and the private key is used to decrypt data; alternatively, the private key is used to sign data, and the public key is used to verify the signature. The public key can be publicly distributed, while the private key must be kept secret. Elliptic curve cryptography is a public-key asymmetric encryption algorithm based on the mathematical structure of elliptic curves. It can utilize the algebraic structure of points on an elliptic curve to create encryption algorithms, providing the same level of security as RSA while using a shorter key length, thus improving efficiency and security. Asymmetric encryption algorithms will be further used in steps S2 and S3.

[0063] In this embodiment, the IP address of the control device is 192.168.1.1, and its public key is Pub. CD The private key is: Pri CD .

[0064] S12: Deploy the IP addresses and corresponding public key data of the field devices to the control device using the configuration tool.

[0065] In this embodiment, the IP address of the field device is 192.168.1.6, and its public key is Pub. FD After deployment, the control device will establish a mapping relationship between the IP addresses and public keys of the field devices. In this embodiment, it is: {192.168.1.6:Pub FD}

[0066] S13: Configure the control device with the IP address of the legitimate field device through the configuration tool. At this point, the control device has obtained the IP address of the field device that can be authenticated.

[0067] S14: Deploy the IP address and corresponding public / private key data of the field device to the field device through the configuration tool.

[0068] In this embodiment, the IP address of the field device is 192.168.1.6, and its public key is: Pub FD The private key is: PriFD .

[0069] S15: Deploy the IP address and corresponding public key data of the control device to the field device through the configuration tool.

[0070] In this embodiment, the IP address of the control device is 192.168.1.1, and its public key is Pub. CD After deployment, the field equipment will establish a mapping relationship between the control device's IP address and public key. In this embodiment, it is: {192.168.1.1:Pub CD}

[0071] It is worth noting that in this embodiment, the private keys of the control device and the field device are respectively deployed in the HSM hardware security module of the control device and the field device. The HSM hardware security module is a hardware device specifically designed to perform encryption operations and protect encryption keys and other confidential data. It can ensure a high level of data security by providing high-performance encryption calculation, key generation, storage and management functions. That is, in this embodiment, the private keys of the control device and the field device are secretly stored in their own HSM modules.

[0072] Furthermore, the IP addresses and corresponding public and private key data of the control device and field devices are stored and entered in PEM text format. PEM is a text format used for storing and transmitting encrypted data, certificates, and keys. It represents binary data using Base64 encoding and adds specific identifier lines before and after the encoded data. That is, in this embodiment, the public key of the control device is Pub. CD Private key Pri CD Public key of field device FD Private key Pri FD All data are in standard PEM format, and the lengths of each public and private key meet the requirements of the corresponding RSA algorithm.

[0073] It should be noted that HART-IP commands are required in the S2 two-way authentication communication process and the S3 session key distribution process. HART-IP commands can be divided into general commands, ordinary commands and special commands. Command codes 0-31, 38 and 48 are general commands, command codes 32-121 (except for commands 38 and 48) are ordinary commands, and command codes 128-253 are special commands, also known as device-defined commands.

[0074] See Figure 3 In a preferred embodiment, the control device sends an authentication request command to the field device in step S2, specifically including the following steps:

[0075] S21: Define HART-IP command code 129 as the authentication request command (other HART-IP command codes can also be used in other embodiments). The control device first sends a message of HART-IP 129 authentication request command to the field device, wherein the control device uses its own RSA private key Pri. CD The hexadecimal number of the last two bytes of its own IP address is encrypted and signed using RSA. In this embodiment, the data obtained by signing 0x101 is denoted as: S. CD The constructed data portion will carry the control device signature data S. CD The authentication request command.

[0076] Furthermore, in S2, the field device parses and verifies the authentication request command and sends an authentication request response back to the control device, specifically including the following steps:

[0077] S22: After receiving the HART-IP 129 authentication request command message, the field device parses the message and obtains the signature data S of the control device. CD Subsequently, the field devices use the public key Pub corresponding to the IP address of the control device. CD For signature data S CD Verification and signature were performed, and the on-site equipment verification and signature data was obtained: VS CD .

[0078] S23: Compare on-site equipment verification data VS CD If the value is the same as the last two bytes of the control device's IP address, the field device authentication of the control device is successful; otherwise, the field device authentication of the control device fails.

[0079] If authentication is successful, the first byte of the data portion of the HART-IP 129 authentication request response message from the field device must be set to 0x00; otherwise, it must be 0x01. Furthermore, the HART-IP 129 authentication request response message must be further populated with the field device's signature data, i.e., the field device uses its own RSA private key Pri. FD The hexadecimal number of the last two bytes of its own IP address is encrypted and signed using RSA. In this embodiment, the data obtained by signing 0x106 is denoted as: S. FD The constructed data portion will carry the field device signature data S. FD The authentication request response.

[0080] Furthermore, in S2, the control device parses and verifies the authentication request response, and then sends the authentication feedback command to the field device again, specifically including the following steps:

[0081] S24: After receiving the HART-IP 129 authentication request response message from the field device, the control device parses the message and first obtains the authentication result of the field device for the control device. If it is 0x01, indicating failure, the failure is recorded and an alarm is triggered. Then, steps S21-S23 are repeated. If it is 0x00, indicating success, the control device continues to obtain the field device signature data S. FD The control device then uses the public key Pub corresponding to the IP address of the field device. FD For signature data S FD Verification was performed, and the verification data of the control equipment was obtained: VS FD .

[0082] S25: Compare the verification data of control equipment with... FD If the value is the same as the last two bytes of the IP address of the field device, it means that the control device has successfully authenticated the field device; otherwise, it means that the control device has failed to authenticate the field device.

[0083] HART-IP command code 130 is defined as the authentication feedback command (other HART-IP command codes can also be used in other embodiments). If authentication is successful, it means that the corresponding control device and field device have successfully completed two-way authentication. The control device will send a message of HART-IP 130 authentication feedback command to the field device. The first byte of the data part of the HART-IP 130 authentication feedback command message of the control device must be set to 0x00, otherwise it is 0x01. After receiving the authentication feedback command message, the field device only needs to determine whether the two-way authentication is successful, without replying with HART-IP 130 command. At this point, the two-way authentication process ends. If the two-way authentication is successful, the session key distribution interaction process continues. Otherwise, the failure is recorded and an alarm is set, and steps S21-S24 are repeated.

[0084] In summary, step S2 utilizes an asymmetric encryption algorithm to achieve identity authentication and authorization functions for both parties communicating in the industrial control system.

[0085] It should be noted that during the session key distribution interaction in S3 and the bidirectional encrypted communication in S4, the encryption algorithms used include AES128-CCM or other symmetric encryption algorithms. AES128-CCM is a symmetric encryption algorithm that combines Advanced Encryption Standard (AES) and Counter Mode with Cipher Block Linked Message Authentication Code (CCM) Mode to simultaneously provide data confidentiality, integrity, and authentication. AES128 Mode uses the AES algorithm with a 128-bit key, while CCM Mode is an authentication encryption mode, thereby ensuring data confidentiality and integrity.

[0086] See Figure 4Preferably, in one embodiment, in S3, the control device encrypts the session key and sends a session key distribution command to the field device, specifically including the following steps:

[0087] S31: The control device uses the HSM module to generate the 16-byte session key SKey required for the AES128-CCM algorithm.

[0088] S32: Define HART-IP command 131 as the session key distribution command (other HART-IP command codes may also be selected in other embodiments), and then the control device uses the RSA public key Pub of the field device it is communicating with. FD The session key SKey is encrypted to obtain the encrypted session key data: En(SKey). Then, the encrypted session key data En(SKey) is hashed to obtain the hash value of the encrypted session key.

[0089] In this embodiment, the hash algorithm used is SHA256, thus obtaining a 32-byte encrypted session key hash value: SHA256(En(SKey)).

[0090] S33: The control device uses its own private key to sign the encrypted session key hash value SHA256(En(SKey)), obtaining the encrypted session key hash value signature data Sign(SHA256(En(SKey))), and constructs a session key distribution command that carries the encrypted session key En(SKey) and the encrypted session key hash value signature data Sign(SHA256(En(SKey))) in the data part. The control device then sends the HART-IP 131 session key distribution command to the field device.

[0091] Furthermore, in S3, the field device parses and verifies the session key distribution command, decrypts it to obtain the session key, and specifically includes the following steps:

[0092] S34: After receiving the HART-IP 131 session key distribution command message, the field device parses the message to obtain the encrypted session key En(SKey) and the encrypted session key hash signature data Sign(SHA256(En(SKey))) from the control device. The field device then uses the public key Pub of the control device it is communicating with. CDThe encrypted session key hash value signature data Sign(SHA256(En(SKey))) is verified. If verification fails, the control device fails to distribute the interactive session key to the field device, and the data portion of the field device's HART-IP 131 response message is filled with 0x01; otherwise, it is filled with 0x00. If verification succeeds, the field device uses its own RSA private key Pri. FD The encrypted session key En(SKey) is decrypted to obtain the decrypted data: De(En(SKey)). Based on the symmetric encryption and decryption characteristics of the AES128-CCM algorithm, it can be seen that De(En(SKey)) is equal to SKey, that is, the field device obtains the session key SKey set by the control device.

[0093] Once the session key SKey is successfully distributed, a secure connection is established between the control device and the field device. Subsequent HART-IP communication data will be encrypted and decrypted using the aforementioned session key SKey.

[0094] Preferably, the session key SKey update cycle is set to 24 hours. When the session key update cycle expires, the control device will automatically update the session key and re-perform the session key encryption and distribution task, thereby fully ensuring the confidentiality of communication and the security of the session key.

[0095] In summary, step S3 utilizes asymmetric encryption and hash algorithms to achieve a more secure key distribution function for industrial control systems.

[0096] See Figure 5 Preferably, in one embodiment, in S4, the control device and the field device respectively perform encryption and decryption operations on the sent and received message data based on the session key, specifically including the following steps:

[0097] S41: The message data sent by the control device to the field device includes request data Data. The control device will perform a hash calculation on the request data Data in the message data to be sent. In this embodiment, the hash algorithm is selected as SHA1, that is, the hash calculation result of the request data Data is SHA1(Data). Therefore, the message data sent by the control device to the field device actually carries its own request data Data and the first request data hash value SHA1(Data). 1 .

[0098] S42: The control device uses the AES128-CCM symmetric encryption algorithm to encrypt the entire HART-IP message data to be sent. The encryption key is the session key SKey mentioned above. Then the control device sends the encrypted message data to the field device.

[0099] S43: The field device receives the encrypted HART-IP message data, first decrypts the encrypted message data using the session key SKey and the AES128-CCM algorithm, and then performs a hash calculation on the request data Data in the decrypted message to obtain the second request data hash value SHA1(Data). 2 The hash value SHA1(Data) of the first request data is then used. 1 The hash value SHA1(Data) of the second request data. 2 The two are compared. If they are the same, the message data is available and the field device responds to the control device. If they are different, the message data may have been tampered with, the message data is unavailable, and the field device does not respond to the control device.

[0100] S44: Similarly, the message data sent back by the field device to the control device also includes request data Data. The field device will perform a hash calculation on the request data Data in the message data to be sent to obtain the third request data hash value SHA1(Data). 3 That is, the message data sent by the field device to the control device actually carries its own request data (Data) and the hash value of the third request data (SHA1(Data)). 3 .

[0101] S45: The field device uses the AES128-CCM symmetric encryption algorithm to encrypt the entire HART-IP message data to be sent. The encryption key is also the session key SKey mentioned above. Then the field device sends the encrypted message data to the control device.

[0102] S46: The control device receives the encrypted HART-IP message data, first decrypts the encrypted message data using the session key SKey and the AES128-CCM algorithm, and then performs a hash calculation on the request data Data in the decrypted message to obtain the hash value SHA1(Data) of the fourth request data. 4 The hash value SHA1(Data) of the third request data is then used. 3 The hash value SHA1(Data) of the fourth request data. 4 The two are compared. If they are the same, the message data is available and the control device responds to the field device. If they are different, the message data may have been tampered with, the message data is unavailable, and the control device does not respond to the field device.

[0103] S47: Repeat steps S41-S46 until the communication task between the control device and the field device is completed. During this bidirectional communication process, all message data sent and received by the control device and the field device must be encrypted and decrypted using the session key, and the request data must be compared and verified using a hash algorithm to prevent the bidirectional message data from being maliciously tampered with during transmission.

[0104] In summary, this embodiment provides a two-way authentication and encrypted communication method based on the HART-IP protocol. Building upon the HART-IP protocol, it achieves two-way authentication and encrypted data communication between control devices and field devices through customized HART-IP command codes. A hash algorithm is employed to ensure communication integrity, addressing the vulnerabilities of plaintext data transmission in the HART-IP protocol, which is susceptible to theft, tampering, and man-in-the-middle attacks. This effectively enhances data security and reliability during communication and solves the problem that traditional industrial control systems can only encrypt data but cannot perform authentication. Furthermore, this embodiment uses the native HART-IP protocol to establish a secure communication connection without using other complex security protocol stacks. This ensures the confidentiality and integrity of communication without consuming excessive industrial control equipment resources or affecting the real-time performance of the industrial control system, significantly reducing the resource consumption and requirements of control devices and field devices during communication. Furthermore, this embodiment only uses a two-way authentication and key distribution scheme based on asymmetric encryption algorithm before the control device and the field device establish a secure communication connection. After the secure communication is established, both parties use the symmetric encryption algorithm AES128-CCM. The overhead of the symmetric encryption algorithm is much smaller than that of the asymmetric encryption algorithm. Therefore, the encrypted communication after the secure connection is established will not consume too much device resources and will not affect the real-time requirements of the industrial control system.

[0105] The embodiments of the present invention have been described in detail above with reference to the accompanying drawings, but the present invention is not limited to the above embodiments. Even if various changes are made to the present invention, if these changes fall within the scope of the claims of the present invention and their equivalents, they shall still fall within the protection scope of the present invention.

Claims

1. A two-way authentication and encrypted communication method based on the HART-IP protocol, characterized in that, Includes the following steps: S1: Deploy the IP addresses and corresponding public and private key data of the control device and the field device respectively to the control device and the field device using a configuration tool; S2: The control device sends an authentication request command to the field device based on the HART-IP protocol. The field device parses and verifies the authentication request command and sends an authentication request response back to the control device. The control device parses and verifies the authentication request response and sends an authentication feedback command to the field device again, thereby realizing two-way identity authentication between the control device and the field device. Specifically, the steps include the following: S21: Define HART-IP command code 129 as an authentication request command. The control device sends the authentication request command message to the field device. The control device uses its own private key to perform encryption signature calculation on the hexadecimal number of the last two bytes of its own IP address. The constructed data part will carry the authentication request command with the signature data of the control device. S22: After receiving the authentication request command message, the field device parses the message, wherein the field device uses the public key corresponding to the IP address of the control device to verify the signature data of the control device, and obtains the field device signature verification data; S23: Compare the value of the field device's signature verification data with the last two bytes of the control device's IP address. If they are the same, the field device successfully authenticates the control device. The first byte of the data portion of the field device's HART-IP 129 authentication request response message must be set to 0x00, and the field device uses its own private key to perform an encrypted signature calculation on the hexadecimal number of the last two bytes of its own IP address, constructing the authentication request response message that carries the field device's signature data. If they are different, the field device fails to authenticate the control device, and the first byte of the data portion of the field device's authentication request response message must be set to 0x01. S24: After receiving the authentication request response message sent by the field device, the control device parses the message, wherein the control device obtains the authentication result of the field device for the control device, and uses the public key corresponding to the IP address of the field device to verify the signature data of the field device, thereby obtaining the signature verification data of the control device; S25: Compare the value of the signature verification data of the control device with the last two bytes of the IP address of the field device. If they are the same, the control device successfully authenticates the field device and sends an authentication feedback command to the field device again. If they are different, the control device fails to authenticate the field device. S3: After encrypting the session key, the control device sends a session key distribution command to the field device based on the HART-IP protocol. The field device parses and verifies the session key distribution command and decrypts it to obtain the session key. S4: The control device and the field device respectively perform encryption and decryption operations on the sent and received message data based on the session key to realize encrypted communication between the control device and the field device.

2. The bidirectional authentication and encrypted communication method based on the HART-IP protocol as described in claim 1, characterized in that, In S1, the IP addresses and public / private key data are deployed to the control device and the field device, specifically including the following steps: S11: The IP address and corresponding public and private key data of the control device are deployed to the control device through a configuration tool, wherein the private key data is deployed in the HSM hardware security module of the control device; S12: Deploy the IP address and corresponding public key data of the field device to the control device using a configuration tool; S13: Configure the IP address of the valid field device to the control device using the configuration tool; S14: Deploy the IP address and corresponding public and private key data of the field device to the field device through the configuration tool, wherein the private key data is deployed in the HSM hardware security module of the field device; S15: Deploy the IP address and corresponding public key data of the control device to the field device using a configuration tool.

3. The bidirectional authentication and encrypted communication method based on the HART-IP protocol as described in claim 2, characterized in that, The IP addresses and corresponding public and private key data of the control device and the field device are all stored and entered in PEM text format.

4. The bidirectional authentication and encrypted communication method based on the HART-IP protocol as described in claim 1, characterized in that, In S3, the control device encrypts the session key and sends a session key distribution command to the field device, specifically including the following steps: S31: The control device uses the HSM module to generate a 16-byte session key required for the symmetric encryption algorithm; S32: The control device uses the public key of the field device with which it communicates to encrypt the session key, and performs a hash calculation on the encrypted session key data to obtain the encrypted session key hash value; S33: The control device uses its own private key to sign the encrypted session key hash value and constructs a session key distribution command whose data part carries the encrypted session key and the encrypted session key hash value signature data.

5. The bidirectional authentication and encrypted communication method based on the HART-IP protocol as described in claim 4, characterized in that, In S3, the field device parses and verifies the session key distribution command, and decrypts it to obtain the session key. This specifically includes the following steps: S34: The field device uses the public key of the control device with which it communicates to verify the signature data of the encrypted session key hash value. If the verification is successful, the field device further uses its own private key to decrypt the encrypted session key to obtain the session key. If the verification fails, the task of the control device to distribute and exchange the session key with the field device fails.

6. The bidirectional authentication and encrypted communication method based on the HART-IP protocol as described in claim 5, characterized in that, The session key update cycle is 24 hours. When the session key update cycle expires, the control device updates the session key and re-performs the session key encryption and distribution task.

7. The bidirectional authentication and encrypted communication method based on the HART-IP protocol as described in claim 1, characterized in that, In S4, the control device and the field device respectively perform encryption and decryption operations on the sent and received message data based on the session key, specifically including the following steps: S41: The control device performs a hash calculation on the request data in the message data to be sent to obtain the hash value of the first request data; S42: The control device uses a symmetric encryption algorithm to encrypt the message data to be sent, and the encryption key is the session key. The control device then sends the encrypted message data to the field device. S43: The field device receives the encrypted message data and uses the session key to decrypt the encrypted message data. It performs a hash calculation on the request data in the decrypted message to obtain a second request data hash value. It compares the first request data hash value with the second request data hash value. If they are the same, the message data is available and the field device responds to the control device. If they are different, the message data is unavailable and the field device does not respond to the control device. S44: The field device performs a hash calculation on the request data in the message data to be sent to obtain the hash value of the third request data; S45: The field device uses a symmetric encryption algorithm to encrypt the message data to be sent, and the encryption key is the session key. The field device then sends the encrypted message data to the control device. S46: The control device receives the encrypted message data and decrypts the encrypted message data using the session key. It performs a hash calculation on the request data in the decrypted message to obtain a fourth request data hash value. It compares the third request data hash value with the fourth request data hash value. If they are the same, the message data is available and the control device responds to the field device. If they are different, the message data is unavailable and the control device does not respond to the field device. S47: Repeat steps S41-S46 until the communication task between the control device and the field device ends.

Images