METHOD AND SYSTEM FOR CREATING A SECURE COMMUNICATION CHANNEL

BACKGROUND

[0001 ] Industrial control systems may include one or more smart monitoring devices. These smart monitoring devices may be configured to measure data relating to one or more aspects of an industrial control system (e.g., control system operating parameters). The measured data may then be used to make real-time adjustments to the industrial control system. To aid data transmission, some smart monitoring devices may be configured to open communication channels and transmit measured data to a remote client. System operators may then monitor and adjust the industrial control system from the remote client.

SUMMARY

[0002] The present disclosure presents new and innovative methods and systems for creating secure communication channels. In one example, a method includes, at a remote client, opening a communication socket to establish communication with an embedded device; generating, at the remote client, an authentication code and encrypting the authentication code with a static device public key to create an encrypted authorization code. The static device public key was previously delivered externally to the remote client. The method may further include transmitting the encrypted authentication code from the remote client to the embedded device, decrypting the encrypted authentication code at the embedded device with a static device private key, and confirming receipt by the embedded device of the authentication code. The method may also include generating, at the device, a temporary device keypair including a temporary device private key and the temporary device public key, generating, at the remote client, a temporary client keypair including a temporary client private key and a temporary client public key, and exchanging, between the embedded device and the remote client, the temporary device public key and the temporary client public key. The method may further include generating, at the embedded device, a shared secret based on the temporary device private key and the temporary client public key; generating, at the remote client, the shared secret based on the temporary client private key and the temporary device public key and generating a session key at both the embedded device and the client based on the shared secret and the authentication code. The method may then include communicating, between the remote client and the embedded device, by encrypting messages using the session key.

[0003] In another example, the negotiation procedure used to generate the shared secret is a Diffie-Hellmann with elliptic curves algorithm, where the elliptic curves used therein are fixedly assigned. In a still further example, the method may include generating the temporary device keypair and the temporary client keypair and exchanging the temporary device public key and the temporary client public key further includes generating, at the embedded device, the temporary device keypair including the temporary device private key and the temporary device public key, and transmitting the temporary device public key from the embedded device to the remote client. The method may also include generating, at the remote client, the temporary client keypair including the temporary client private key and the temporary client public key and transmitting the temporary client public key from the remote client to the embedded device. In another example, the method may further include generating an encryption initialization vector at both the embedded device and the remote client based on the session key and the authentication code. In a further example, the static device public key is previously installed on the remote client. In another example, the static device private key is permanently stored on a secure memory of the embedded device. In a further example, communicating between the remote client and the embedded device uses packets that are formatted to include (1 ) an encrypted message of length N ^* 16 bytes, where N is an indication of the number of blocks constituting the encrypted message, and (2) a header that stores an indication of the value of N. In another example, N = (L + 15) / 16, wherein L is the length of the unencrypted message. In another example, the header has a length of 1 byte. In another example, the embedded device acknowledges reception of the temporary client public key. In a further example, the communication socket is opened according to the TCP protocol. In a still further example, the static device private key and the static device public key are generated using an RSA system. In another example, the session key is generated using the HMAC-SHA256 algorithm. In a further example, messages are encrypted using the AES symmetric cipher in CBC mode. In a still further example, the steps of the method are performed to enable a plurality of embedded devices to communicate with the remote client by encrypting messages.

[0004] In another example, a system comprises an embedded device comprising a first processor and a first memory and a remote client comprising a second processor and a second memory. The first memory and the second memory contain instructions which, when executed by the first processor and the second processor, cause the first processor and the second processor to, at the remote client, open a communication socket to establish communication with an embedded device and generate an authentication code. The first memory and the second memory may contain further instructions which, when executed by the first processor and the second processor, cause the first processor and the second processor to encrypt, at the remote client, the authentication code with a static device public key to create an encrypted authorization code. The static device public key was previously delivered externally to the remote client. The first memory and the second memory may contain further instructions which, when executed by the first processor and the second processor, cause the first processor and the second processor to transmit the encrypted authentication code from the remote client to the embedded device, confirm receipt by the embedded device of the authentication code, generate, at the device, a temporary device keypair including a temporary device private key and the temporary device public key, and generate, at the remote client, a temporary client keypair including a temporary client private key and a temporary client public key. The first memory and the second memory may contain further instructions which, when executed by the first processor and the second processor, cause the first processor and the second processor to exchange, between the embedded device and the remote client, the temporary device public key and the temporary client public key. The first memory and the second memory may contain further instructions which, when executed by the first processor and the second processor, cause the first processor and the second processor to generate, at the embedded device, a shared secret based on the temporary device private key and the temporary client public key, and generate, at the remote client, the shared secret based on the temporary client private key and the temporary device public key. The first memory and the second memory may contain further instructions which, when executed by the first processor and the second processor, cause the first processor and the second processor to generate a session key at both the embedded device and the client based on the shared secret and the authentication code; and communicate, between the remote client and the embedded device, by encrypting messages using the session key.

[0005] The features and advantages described herein are not all-inclusive and, in particular, many additional features and advantages will be apparent to one of ordinary skill in the art in view of the figures and description. Moreover, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes, and not to limit the scope of the inventive subject matter.

BRIEF DESCRIPTION OF THE FIGURES

[0006] FIG. 1 illustrates a system for opening a secure communication channel according to an example embodiment of the present disclosure. [0007] FIG. 2 illustrates a flow diagram of an example method for opening a secure communication channel according to an example embodiment of the present disclosure.

[0008] FIG. 3 illustrates a diagram of example calculation dependencies according to an example embodiment of the present disclosure.

[0009] FIG. 4 illustrates a flow diagram of an example message encryption according to an example embodiment of the present disclosure.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

[0010] Because smart monitoring devices may measure data relating to confidential or sensitive industrial systems, it may be advantageous to configure the smart monitoring devices to open secure communication channels that encrypt the messages sent between the smart monitoring device and the remote client. For example, some smart monitoring devices may be configured to use the Transmission Control Protocol (TCP) and the Transportation Layer Security (TLS) protocol.

[0011 ] However, demand for lower-cost monitoring devices has increased as more industrial control systems are updated and designed to incorporate smart monitoring devices. These lower-cost monitoring devices are less likely to have the computing resources necessary to properly implement TLS and similar protocols. Additionally, many smart monitoring devices are designed for longer service lives (e.g., 10 or more years). Thus, there are still many devices in service whose hardware is relatively old and outdated and thus may not be able to run more full-featured protocols such as TLS.

[0012] One of the issues associated with these full-featured protocols is that they include many features and configuration options that are not used during smart monitoring device data transmissions. For example, TLS supports the customization of many transmission parameters, including the ciphering algorithm, digest method, and key negotiation algorithm. In order to support this level of customizability, TLS imposes a large computing and memory-usage burdens relative to the resources available on most smart monitoring devices. Thus, many of these devices may be unable to use TLS and similar protocols to create secure communication channels.

[0013] One innovative solution to this problem is to create a secure communication channel using a protocol that is limited to the functional and performance requirements of smart monitoring devices. Such a protocol may remove the configuration potential of TLS in order to reduce the computing resources required. For example, as described in greater detail below, the protocol may provide a more limited set of key exchange systems and ciphering systems. This new protocol may be optimized for data acquisition settings as well. These settings, which are typical for smart monitoring devices, often have smaller data transmissions because the smart monitoring devices transmit in real-time. Thus, optimizing the protocol for smaller message sizes may reduce the memory and computing requirements without affecting the smart monitoring device’s ability to perform as required. Additionally, to avoid“chain of trust” requirements, the protocol may employ raw RSA keys instead of security certificates. By using raw RSA keys, the protocol may enable devices to verify one another without having to connect to a security server, which may be difficult within an industrial control system. One example system implementing this technique is the ComAp® Crypto Suite.

[0014] Figure 1 depicts a system 100 for opening a secure communication channel according to an example embodiment of the present disclosure. The system 100 includes a control system 102 and a remote client 126. The control system 102 includes actuators 105, 107, which may be used to control one or more physical devices in the control system102 . The control system 102 also includes an embedded device 104, which includes a microcontroller 109 containing a memory 1 10, a CPU 124, and a secure memory 106 containing a static device private key 108. The secure memory 106 may be implemented as an NVRAM (e.g., an FRAM or FLASH device) contained within the CPU 124. In some implementations, the secure memory 106 restricts access such that only firmware running within the processor 124 is capable of accessing it. Such an implementation may prevent the secure memory 106 from being read by any interface other than the CPU 124. The memory 1 10 contains an authentication code 1 18, a shared secret 120, a session key 122 and a temporary device keypair 1 12 containing a temporary device public key 1 14 and a temporary device private key 1 16. The remote client 126 contains a CPU 144 and a memory 128. The memory 128 contains an authentication code 136, a shared secret 138, a session key 140, a static device public key 142, and a temporary client keypair 130 containing a temporary client public key 132 and a temporary client private key 134. In certain implementations, as depicted in Figure 1 , the memory 1 10, the CPU 124, and the secure memory 106 may be contained within the microcontroller 109. Such internal implementations may mitigate security concerns that would result if the components were external to such a microcontroller.

[0015] The system 100 may be used to create a secure communication channel between the embedded device 104 and the remote client 126. The secure communication channel may be used to transmit monitoring data from the embedded device (e.g., monitoring data stored in the memory 1 10) to the remote client 126 and to issue control system commands from the remote client 126 to the embedded device 104 to initiate control of the control system 102. The remote client 126 may then process the monitoring data to control or monitor the status of the control system 102. The embedded device 104 and remote client 126 may be configured to communicate wirelessly. For example, the embedded device 104 and remote client 126 may be configured to communicate using Wi-Fi, Bluetooth, ZigBee, Z-Wave, ethernet, and cellular data or any other wireless protocol. In an example, the remote client 126 communicates wirelessly with a network that communicates via a wired connection with the embedded device 104.

[0016] The embedded device 104 may be configured to collect one or more types of monitoring data related to the control system 102. For example, the embedded device 104 may be configured to collect operational parameters including one or more of an operating temperature, an air pressure, an air speed, a fluid flow rate, a hydraulic pressure, a number of revolutions per minute, an energy usage, a power, a voltage, a current, or any other operating parameter. The embedded device 104 may also record an operational log including a plurality of events that the embedded device 104 monitored and may receive new operational setpoints. The embedded device 104 may also be configured to control one or more aspects of the control system 102. For example, the control system 102 may be a heating system and the embedded device 104 may be configured to issue control signals that change the air flow rate or air temperature of the air handled by the system. Alternatively, the control system 102 may be a lift and the embedded device 104 may be configured to control the lift by issuing control signals to change elevation, or to stop at a particular location. The embedded device 104 may also be configured to receive firmware updates and configuration files.

[0017] The memory 1 10 contains items that may be used while creating a secure channel. As described further below, the authentication code 118 may be used to generate the session key 122. The temporary device private key 1 16 may be used in calculating the shared secret 120, which may be used to calculate the session key 122. The session key 122 may then be used to encrypt messages (e.g., messages containing monitoring information or control system commands) that are sent using the secure communication channel between the embedded device 104 and the remote client 126. Similarly, the secure memory 106 contains the static device private key 108, which may be used to decrypt a received encrypted authentication codeas described further below.

[0018] The remote client 126 may be configured to receive and process monitoring data from the embedded device 104. For example, the remote client 126 may be configured to receive monitoring data from the embedded device 104 and store the monitoring data in a memory 128. The remote client 126 may also process the received monitoring data to present historical information on the monitoring data received. For example, the remote client 126 may include a display used to display the information. The remote client 126 may be further configured to generate an alert or perform other actions based on the monitoring data. For example, if the monitoring data includes an operating temperature, the remote client 126 may be configured to issue an alert if the operating temperature exceeds or drops below a certain threshold.

[0019] The remote client 126 may also be configured to transmit control system commands to the embedded device 104. As described above, after receiving a control system control system command the embedded device 104 may then issue the control system command to the control system 102, which may then implement the control system command using the actuators 105, 107. In one example, a user may enter a control system command and the remote client 126 may transmit the control system command to the embedded device 104. For example, the user may enter the control system command to increase the air temperature in a heating control system. The remote client 126 may transmit the control system command using the secure communication channel to the embedded device 104, which may then issue the control system command to the control system 102, which may responsively raise the air temperature. In another example, the remote client 126 may automatically generate a control system command. For example, the remote client 126 may receive information that an operating temperature has exceeded a certain threshold and may generate a control system command to reduce the air temperature of a heating system. The remote client 126 may transmit this control system command to the embedded device 104 using the secure communication channel and the embedded device may issue the control system command to the control system 102, which may then reduce the air temperature.

[0020] The memory 128 contains several items that may be used to create a secure communication channel with the embedded device 104. For example, the authentication code 136 may be used to generate the session key 140. The temporary client private key 132 may be used in calculating the shared secret 138, which may be used to calculate the session key 140. The session key 140 may then be used to encrypt messages (e.g., messages containing monitoring information or control system commands) that are sent using the secure communication channel between the embedded device 104 and the remote client 126. The memory 128 also contains a static device public key 142 that may be used to encrypt an authentication code and transmit the encrypted authentication code to the embedded device 104.

[0021 ] In certain implementations, one or more elements contained in the memories 1 10, 128 and the secure memory 106 may be the same. For example, the authentication codes 1 18, 136 may be identical, the shared secrets 120, 138 may be identical, and the session keys 122, 140 may be identical. For example, the shared secrets 120, 138 and the session keys 122, 140 will be identical if the temporary device keypair 1 12 and the temporary client keypair 130 are generated using a keypair ciphering algorithm, as discussed further below. The identical elements may be separately calculated on both the embedded device 104 and the remote client 126. For example, the authentication code 1 18, 136 may be transmitted from the embedded device 104 to the remote client 126 and the shared secret 120, 138 may be separately calculated on both the embedded device 104 and the remote client 126, as described further below. Similarly, although not depicted, the embedded device 104 and the remote client 126 may transmit one or more elements and store received elements in the memories 1 10, 128. For example, the embedded device 104 may transmit the temporary device public key 1 14 and the remote client may store the temporary device public key 1 14 in the memory 128. As another example, the remote client may transmit the temporary client public key 132 and the embedded device 104 may store the temporary client public key 132 in the memory 110.

[0022] The static device public key 142 and the static device private key 108 may be generated using an asymmetric ciphering algorithm, such as the Rivest-Shamir- Adelman (RSA) algorithm, or the EIGamal algorithm. The temporary device private key 1 16, the temporary device public key 114, the temporary client private key 132, and the temporary client public key 134 may be generated using one or more encryption key exchange algorithms, such as the Diffie-Hellmann algorithm. Certain keys 142, 108, 1 16, 114, 132, 134 may be used in the creation of more than one secure communication channel and certain keys 142, 108, 1 16, 114, 132, 134 may be used in the creation of only a single secure communication channel, or of a single communication session on a secure communication channel.. For example, the static device private key 108 and the static device public key may be used the creating more than one secure communication channel and the temporary client public key 132, temporary client private key 134, temporary device public key 1 14, and temporary device private key 1 16 may be generated for each new secure communication channel. Further, the static device public key 142 may be used to create secure communication channels with multiple embedded devices 104. To enable this, the static device public key 142 may be installed in the remote client 126 using configuration software or when the remote client is manufactured or initialized. Installing the static device public key 142 may also permit a secure communication to be formed without relying on a chain of trust or security certificates. This may help avoid man-in-the-middle attacks that attempt to eavesdrop by simulating a connection between the remote client and the embedded device, because the device attempting to perform such an attack would not have the static device private key 108.

[0023] One or both of the embedded device 104 and the remote client 126 may be implemented by a computer system. For example, the CPU 124 and the memory 1 10 may implement one or more features of the embedded device 104 and the CPU 144 and the memory 128 may implement one or more features of the remote client 126. For example, the memory 110 may contain instructions which, when executed by the CPU 124, cause the CPU 124 to perform one or more of the operational features of the embedded device 104. As another example, the memory 128 may contain instructions which, when executed by the CPU 144, cause the CPU 144 to perform one or more of the operational features of the remote client 126.

[0024] Figure 2 depicts a flow diagram of an example method 200 for opening a secure communication channel according to an example embodiment of the present disclosure. The method 200, when executed, may be used to establish and communicate using a secure communication channel between a remote client 202 and an embedded device 204. The method 200 may be implemented on a computer system, such as the system 100. For example, method 200 may be implemented by the remote client 126 and the embedded device 104. The method 200 may also be implemented by a set of instructions stored on a computer readable medium that, when executed by a processor, cause the computer system to perform the method. For example, all or part of the method 200 may be implemented by the CPU 124, 144 and the memory 1 10, 128. Although the examples below are described with reference to the flowchart illustrated in Figure 2, many other methods of performing the acts associated with Figure 2 may be used. For example, the order of some of the blocks may be changed, certain blocks may be combined with other blocks, one or more of the blocks may be repeated, and some of the blocks described may be optional.

[0025] The method 200 begins with the remote client 202 opening a socket (block 206). The socket may be opened according to a protocol such as the Transmission Control Protocol (TCP). The socket may define an internal networking endpoint within the remote client 202 for routing communications received from the embedded device 204. The embedded device 204 may need the socket to properly prepare its transmissions and therefore the remote client 202 may transmit the socket along a public communication channel or by another communication means. The embedded device 204 may then receive the socket information (block 208) and transmit an identification using the socket to indicate that the embedded device 204 is prepared to begin establishing the secure communication channel (block 212). For example, the embedded device 204 may receive a port number indicating the port on which the remote client will be anticipating communications from the embedded device 204 and transmit an identification using the port number to indicate that it is prepared to begin establishing the secure communication channel. In other embodiments, the ports are fixedly adjusted beforehand and the embedded device 204 may receive information on the type of remote client 202 requesting secure communication channel.

[0026] The remote client 202 may then generate an authentication code 136 (block 210). The authentication code 136 may be a random number (e.g., a 256-bit random binary number) used to verify later transmissions. The authentication code may be generated using a pseudo-random number generator or any other similar method. The remote client 202 may then encrypt the authentication code 136 to create an encrypted authentication code (block 214). The encrypted authentication code may be created using an asymmetric encryption algorithm such as RSA. The encrypted authentication code may be encrypted such that the embedded device 204 is able to decrypt the encrypted authentication code using the static device private key 108. For example, the encrypted authentication may be created using the static device public key 308. The remote client 202 may then transmit the encrypted authentication code to the embedded device 204 (block 216). The embedded device 204 may then receive and decrypt the encrypted authentication code to obtain the authentication code 1 18, 136 (block 212). As discussed above, the embedded device 204 may use the static device private key 108 to decrypt the encrypted authentication code. After decrypting the authentication code 118, the embedded device 204 may confirm receipt of the authentication code 1 18 with the remote client. In response, the remote client 202 may request a temporary device public key 114.

[0027] The method 200 may then proceed with the remote client 202 generating a temporary client keypair 130 (block 220) and the embedded device 204 generating a temporary device keypair 112 (block 222). The temporary client keypair 130 may include a temporary client public key 132 and a temporary client private key 134 and the temporary device keypair 1 12 may include a temporary device public key 1 14 and a temporary device private key 1 16. The temporary client keypair 130 and the temporary device keypair 1 12 may be generated so that the public portion of one and the private portion of the other may be used in calculating a shared secret 120, 138. For example, the temporary client keypair 130 may be generated so that a shared secret 120, 138 may be calculated using the temporary client public key 132 and the temporary client private key 134. One or both of the temporary client keypair 130 and the temporary device keypair 112 may be generated using a key exchange algorithm, such as a Diffie-Hellman key exchange algorithm. For example, one or both of the temporary client keypair 130 and the temporary device keypair 1 12 may be generated using the Diffie-Hellman algorithm with fixedly assigned elliptic curves. The remote client 202 may then transmit the temporary client public key 132 to the embedded device 204 and the embedded device 204 may transmit the temporary device public key 1 14 to the remote client 202 (blocks 224, 226). The temporary client public key 132 and the temporary device public key 1 14 may be exchanged openly.

[0028] The remote client 202 and the embedded device 204 may then each generate a shared secret 120, 138 (blocks 228, 230). The remote client 202 and the embedded device 204 may independently generate the shared secret 120, 138. For example, the remote client 202 may generate the shared secret 120, 138 based on the temporary device public key 1 14 and the temporary client private key 134. As another example, the embedded device 204 may generate the shared secret 120, 138 based on the temporary client public key 132 and the temporary device private key 116.

[0029] The remote client 202 and the embedded device 204 may then each calculate a session key 122, 142 (blocks 232, 234). The session key 122, 142 may be a temporary key used for a single secure communication channel and may be generated using a key derivation function (KDF), such as FIMAC-SFIA256, which may advantageously provide a relatively faster computation with lower memory overhead. The remote client 202 and the embedded device 204 may then each calculate an initialization vector (blocks 236, 238). The initialization vector may be calculated based on the session key 122, 140 and may be calculated using a KDF, such as FIMAC- SFIA256. The initialization vector may be used to encrypt communications within the secure communication channel in order to keep the associated transmissions secure. [0030] After calculating the initialization vector, a secure communication channel between the remote client 202 and the embedded device 204 may be established and the remote client 202 and the embedded device 204 may proceed to encrypt and exchange communications using the secure communication channel (blocks 240, 242). The communications may be encrypted using the initialization vector and the session key 122, 140 and may be encrypted using a symmetric encryption standard such as AES. For example, the communications may be encrypted using the AES symmetric cipher standard in cipher block chaining (CBC) mode. Both the remote client 202 and the embedded device 204 may generate and encrypt communications. As discussed above, the remote client 202 may generate and transmit control system commands for a control system 102 and the embedded device 204 may generate and encrypt control system monitoring data, such as operating conditions.

[0031 ] The remote client 202 and the embedded device 204 may maintain the secure communication channel for a set period of time or may terminate the secure communication channel after completing the desired transmissions. After disconnecting, the remote client 202 and the embedded device 204 may repeat the steps to reestablish a new secure communication channel for transmission later in time. Further, each of the remote client 202 and the embedded device 204 may repeat the steps of the method 200 to create secure communication channels with other devices and may have multiple secure communication channels open with multiple other devices at the same time. For example, the embedded device 204 may be connected to a plurality of remote clients and may also be connected to one or more other embedded devices. Likewise, the remote client 202 may be connected to a plurality of embedded devices and one or more other remote clients.

[0032] Figure 3 depicts a diagram of example calculation dependencies 300 according to an example embodiment of the present disclosure. The dependencies 300 may depict calculation dependencies associated with establishing a secure communication channel as described above in connection with the system 100 and the method 200. The dependencies 300 relate to a particular example configuration of the system 100 and the method 200 and thus the system 100 and method 200 may, in certain implementations, include dependencies that differ from the dependencies 300.

[0033] The dependencies 300 include client calculation dependencies 302 and device calculation dependencies 304. The client calculation dependencies 302 may reflect calculations performed by a remote client 126, 202 and the device calculation dependencies 304 may reflect calculations performed by an embedded device 104, 204. Starting with the client calculation dependencies 302, the remote client 126, 202 is provided with the static device public key 308, 142 and generates an authentication code 306, 118, 136. For example, the static device public key 308, 142 may be installed with monitoring and control software used at the remote client 126, 202. The remote client 126, 202 then encrypts the authentication code to create an encrypted authentication code 310 using the authentication code 306, 1 18, 136 and the static device public key 308, 142. Next, the embedded device 104, 204 contains a static device private key 312, 108 and receives the encrypted authentication code 310. The static device private key 312, 108 may have been installed in a secure memory 106 at the time the embedded device 104, 204 was manufactured. The embedded device 104, 204 then uses the static device private key 312 to decrypt the encrypted authentication code 310 and obtain the authentication code 306, 1 18, 136.

[0034] The remote client 126, 202 then calculates the shared secret 318, 120, 138 using the temporary device public key 314, 1 14 received from the embedded device 104, 204 and the temporary client private key 316, 134 generated by the remote client 126, 202. The embedded device 104, 204 also calculates the shared secret 318, 120, 138, but uses the temporary device private key 320, 116 generated by the embedded device 104, 204 and the temporary client public key 132 received from the remote client 126, 202.

[0035] Next, both the remote client 126, 202 and the embedded device 104, 204 may calculate the session key 324, 122, 140 using the shared secret 318, 120, 138 and the authentication code 306, 1 18, 136. The remote client 126, 202 and the embedded device 104, 204 then use both the session key 324, 122, 140 and the authentication code 306, 1 18, 136 to calculate the initialization vector 326. Several of the above calculated keys performed by both the remote client 126, 202 and the embedded device 104, 204 may be performed concurrently and one of the remote client 126, 202 and the embedded device 104, 204 may complete the calculations before the other. For example, the calculations of the shared secret 318, 120, 138, the session key 324, 122, 140, and the initialization vector 326 may be performed concurrently by both the remote client 126, 202 and the embedded device 104, 204.

[0036] The initialization vector 326 may then be used to communicate using the secure communication channel. For example, the remote client 126, 202 and the embedded device 104 may use the initialization vector 326 and the session key 324, 122, 142 to encrypt unencrypted communications 328, 330 and form encrypted communications 332, 334. The encrypted communications 332, 334 may then be transmitted between the embedded device 104, 204 and the remote client 126, 202 using the secure communication channel.

[0037] Figure 4 depicts a flow diagram of an example message encryption 400 according to an example embodiment of the present disclosure. The example message encryption 400 includes an unencrypted message 402, which may include the unencrypted communications 328, 330. The unencrypted message 402 may include control system monitoring data or control system commands as discussed above. The example message encryption 400 also includes a channel encryption procedure 404, which may include a system for encrypting an unencrypted message for use in a secure communication channel. For example, the channel encryption procedure 404 may include all or part of the method 200 (e.g., blocks 240, 242) and may be performed by the system 100. The example message encryption 400 also includes an encrypted message 408 and a header 406. [0038] The unencrypted message 402 may be created by a remote client 126, 202 or an embedded device 104, 204 while monitoring or operating a control system 102. The unencrypted message 402 may have a length of L bytes. The unencrypted message 402 may then be encrypted using the channel encryption procedure 404 to create the encrypted message 408. The encrypted message 408 may have a length of N ^* 16 bytes, where N is the number of blocks in the encrypted message 408. In one implementation, N may be determined according to the equation N = (L + 15) / 16, where L is the length of the unencrypted message 402 as described above. Such an implementation may improve performance of the channel encryption procedure 404 by the remote client 126, 202 and the embedded device 104, 204. However, the relationship between N and L may vary depending on the channel encryption procedure 404. The channel encryption procedure 404 may also create the header 406 appended to the encrypted message 408. The header 406 has a length of 1 byte as depicted, but may have a different length in some implementations. The header 406 may contain a representation of N, the number of blocks in the encrypted message 408. After being generated, the header 406 and the encrypted message 408 may then be transmitted between the embedded device 104, 204 and the remote client 126, 202 using the secure communication channel. In some embodiments, the encrypted message 408 and the header 406 may enable secure communication with smaller message sizes, which may advantageously enable devices with limited memory to communicate using secure communication channels.

[0039] All of the disclosed methods and procedures described in this disclosure can be implemented using one or more computer programs or components. These components may be provided as a series of computer instructions on any conventional computer readable medium or machine readable medium, including volatile and non-volatile memory, such as RAM, ROM, flash memory, magnetic or optical disks, optical memory, or other storage media. The instructions may be provided as software or firmware, and may be implemented in whole or in part in hardware components such as ASICs, FPGAs, DSPs, or any other similar devices. The instructions may be configured to be executed by one or more processors, which when executing the series of computer instructions, performs or facilitates the performance of all or part of the disclosed methods and procedures.

[0040] It should be understood that various changes and modifications to the examples described here will be apparent to those skilled in the art. Such changes and modifications can be made without departing from the spirit and scope of the present subject matter and without diminishing its intended advantages. It is therefore intended that such changes and modifications be covered by the appended claims.