WO2021077039A1

WO2021077039A1 - Encrypted tunnel

Info

Publication number: WO2021077039A1
Application number: PCT/US2020/056184
Authority: WO
Inventors: David Martin; Kevin HENSON; Peter Dylan SHARAR
Original assignee: Allied Special Operations Group, Llc
Priority date: 2019-10-16
Filing date: 2020-10-16
Publication date: 2021-04-22

Abstract

A method, system and apparatus for secure communication between a first node and a second node separated by an untrusted network. The method, system and apparatus provides a first virtual private network and a second virtual private network disposed within the first virtual private network. Command signals within the secure channel are obscured by signals on one or more false channels transmitting parallel to a command channel.

Description

ENCRYPTED TUNNEL

TECHNICAL FIELD OF THE DISCLOSURE

[ 0001 ] This disclosure relates generally to the field of network communications, and more specifically to a system and method for securing critical systems network communications .

SUMMARY OF THE PRESENT DISCLOSURE

[ 0002 ] The present disclosure relates to systems and methods for securing communications over a network infrastructure. In particular, the present disclosure is directed to securing network communications between a client node and a server node, so as to prevent access or interference by third-party nodes. The enhanced security is provided via the use of an encrypted tunnel between client and server, which passes through the network infrastructure, thereby connecting client and server in a secure manner.

[ 0003 ] In the embodiments disclosed, the server is connected to a variety of industrial control systems (ICS), such as a Remote Terminal Unit (RTU), Intelligent

Electronic Device (TED) or Programmable Logic Controller (PLC) within an industrial control system. Those of skill in the art will recognize that the teachings of the present disclosure are applicable in many applications. In certain embodiments, the server may be disposed within a secured enclosure to prevent physical access. In such embodiments, all communications between the client and server taking place outside of the secure enclosure are encrypted.

[0004] The supported network infrastructure could be any wide area network, including but not limited to the internet. The client could be selected from a variety of devices, including but not limited to a human machine interface (HMI) within a Supervisory Control and Data Acquisition (SCADA) implementation. The encrypted tunnel within an encrypted tunnel can be established via a number of known methods, included but not limited to an OpenVPN solution. In certain embodiments, encryption and decryption are facilitated via a 256-bit AES:CBC 4096 Diffie-Helman exchange, but other encryption methodologies may be employed in alternate embodiments.

[0005] The encrypted tunnels provide end-to-end encryption from the client to the server, which is connected to the

RTU, TED or PLC. The server is located at one end of tunnel and physically attached to the device being read and controlled.

BRIEF DESCRIPTION OF THE DRAWINGS

[0006] For a more complete understanding of the present disclosure, and for further features and advantages, reference is now made to the following description, taken in conjunction with the accompanying drawings, in which:

[0007] Figure 1 shows a block diagram of a network 100 according to certain embodiments of the present disclosure;

[0008] Figure 2 shows a schematic diagram of the network 100 of Figure 1 according to certain embodiments of the present disclosure;

[0009] Figure 3 depicts a flowchart illustrating a method of operation of an encrypted security system;

[0010] Figure 4 depicts an encrypted SCADA transport architecture according to one embodiment of the present disclosure;

[0011] Figure 5 provides additional detail as to the secure solution 200 shown in Figure 4;

[0012] Figure 6 depicts additional operational details of secure communications core 270; [0013] Figure 7 shows a site device 300 suitable for use in an industrial environment, to provide secure communication with an industrial device over an untrusted network;

[0014] Figure 8 shows a human machine interface (HMI) client 400 according to certain embodiments of the present disclosure; and

[0015] Figures 9A and 9B show a flowchart detailing the method according to one embodiment of the secure solution of the present disclosure.

DETAILED DESCRIPTION OF THE DRAWINGS

[0016] Figures 1 and 2 show a network 100 according to the present disclosure. Network 100 incorporates a wide area network (WAN) 102 and a local area network (LAN) 104. Wide area network 102 facilitates communication between various nodes connected to network 100, including but not limited to client 106, server 108 and third-party node 110. The present disclosure is directed to securing network communications through WAN 102 between client 106 and server 108, so as to prevent access or interference by third-party node 110. The security is provided via the use of an encrypted tunnel 112 between client 106 and server 108, which passes through WAN 102, through LAN router 114 to server 108, thereby connecting client 106 and server 108 in a secure manner.

[0017] In the embodiments shown in Figures 1 and 2, server 108 is connected via signal 116 to a Remote Terminal Unit (RTU) 118 within an industrial control system, but those of skill in the art will recognize that the teachings of the present disclosure are applicable in many applications. In the embodiment shown in Figure 2, RTU 118 is physically disposed within a secure enclosure 120 to prevent unauthorized physical access. In certain embodiments, server 108 may be disposed within the same secure enclosure

120 as RTU 118. In such embodiments, all communications between client 106 and server 108 taking place outside of secure enclosure 120 are encrypted.

[0018] WAN 102 could be any wide area network, including but not limited to the internet. Client 106 could be selected from a variety of devices, including but not limited to a human machine interface (HMI) within a Supervisory Control and Data Acquisition (SCADA) implementation. Encrypted tunnel 112 can be established via a number of known methods, included but not limited to an OpenVPN solution. In certain embodiments, encryption and decryption are facilitated via a 256-bit AES:CBC 4096 Diffie-Helman exchange, but other encryption methodologies may be employed in alternate embodiments.

[0019] Encrypted tunnel 112 provides end-to-end encryption from the client 106 to the server 108, which is connected to RTU 118 via signal 116. Server 108 is located at one end of tunnel 112 and physically attached to the device being read and controlled (in this case RTU 118). Client 106 serves as a controlling interface at the opposite end of secure tunnel 112. Thus, client 106 has control over connections and the scenario is not dependent on the server 108 or RTU 118 sending out requests to client 106 that could be intercepted and controlled by third-party node 110. In certain embodiments, server 108 only allows one connection at a time. In certain embodiments, Address Resolution Protocol (ARP) bindings and static addresses and routes are required on server 108, the remote LAN, and the controlling interface LAN. This scenario guards against interceptions, human error, and turbulent networking scenarios. In certain embodiments, port forwarding is required to allow client 106 to reach server 108 and must only be allowed with one port forwarded per device. This arrangement protects client 106, which is more likely to contain vulnerabilities. Allowing only one port forwarded per device forces any connections through WAN 102 to be ported solely to server 108, which only responds with the correct password and certificate.

[ 0020 ] The encryption client software used, such as OpenVPN, will be installed on client 106. When setting up the encrypted tunnelling solution, it may be necessary to set up port forwarding on the way out of the LAN (if any) for client 106 and on the way in from the internet through LAN 104. It is preferable that RTU 118 have a static IP that does not conflict with any IP addresses already present. It is also preferable that ports used for port forwarding not be the same ports used anywhere else in the infrastructure. This could open them to scanning and attack.

[ 0021 ] A wide variety of variations are possible within the above-described framework. Update servers may be maintained, which may use secure I2P protocols configured to only transmit among guarded known I2P gateways. This combination and configuration guards against electromagnetic readings and reverse engineering with the pseudorandom data bits, by devices such as a chip whisperer. This arrangement also guards against reconnaissance and enumeration as not even an attacker with access to either LAN can read any traffic, and on the device LAN, is not free to roam and recon the device, as the device is guarded by server 108 and routing protocol protections located physically attached to the actual controlled device. Devices not using this solution would be able to be exploited if an attacker reached this far. If an attacker tries to de-authorize, or successfully mount a denial of service (DOS) attack on the external secure tunnel to read the contents, they will only gain access to a much stronger and more secure tunnel. In such an event, and the external secure tunnel will read and report this breach, and be reestablished very quickly, giving the attacker only a short time to access the more strongly encrypted data, whilst giving away their technique and location.

[ 0022 ] If this configuration is built into a single protected unit, even an attacker located on site would not be able to physically plug in to read transmissions locally. Connecting to the on-site LAN would give them nothing but the external IP of the encryption/routing device. This information is not useful, as the guarded IP is located internally, and then only allowed to communicate to connections routed from the internal tunnel, which must be established with a certificate, plus only one connection is allowed at a time anyway, with static addresses and routing, and ARP bindings, all inside of an encrypted secure tunnel.

[ 0023 ] As noted, it is desirable that port forwarding be enabled on the way out from the client 106 controller until the internet is reached, and on the way in from the internet to LAN 104. It is preferable that the SCADA infrastructure not operate anywhere on the same port as the

OpenVPN tunnel. If the infrastructure does operate on the same port as the OpenVPN tunnel, the infrastructure may be exposed to scans and attacks.

[0024] In certain embodiments, port 443 may be used the entire way across the network, on incoming and outgoing port forwarded OpenVPN connections (except on the "wild" Internet WAN Router). This can also be changed, but is not necessary to do so, and to do so provides no further levels of security.

[0025] A method of establishing and maintaining secure tunnel 112 is disclosed in Figure 3. Process begins in block 150. In block 152, the encryption key is loaded. In block 154, secure tunnel 112 is established. Secure tunnel 112 is constantly monitored by a while loop that reestablishes secure tunnel 112 should it be attacked or fail. Within first secure tunnel 112, a second secure tunnel is established. Even the initial handshake and connection needed to establish the second secure tunnel is protected and encrypted within the first secure tunnel 112. In block 156, the encrypted controller software data is loaded. In block 158, pseudorandom data is generated and sent through the secure tunnel. In block 160, encrypted data is transmitted to the device alongside the pseudorandom data. In block 162, additional pseudorandom data is sent. In block 164, the control data is decrypted.

In block 166, the decrypted data is relayed to the RTU. In block 168, the RTU receives and acts on the received control data. If there is more control data (block 170) process flow returns to block 154. If not, process flow ends at block 172.

[0026] Figure 4 depicts an encrypted SCADA transport architecture according to one embodiment of the present disclosure. This architecture includes a secure communication solution 200 to provide for secure communications between a human machine interface (HMI) 202 such as an industrial control system, and an industrial controller 204. The details of the operation of secure communication solution 200 are addressed elsewhere in the present disclosure.

[0027] Human machine interface 202 may be operationally connected to a variety of components, including remote diagnostics and maintenance components 206. Human machine interface 202 may also be connected to networked components on the other side via a router or switch 208 providing networked access to corporate data network 210. HMI 202 may also connect to the internet 214 via firewall 212. [0028] In addition to being connected to secure solution

200, industrial controller 204 may be connected, directly or indirectly, to an array of industrial components on the industrial side of secure solution 200. These may include, but are not limited to, a data historian 220, various sensors 222, various actuators 224 and industrial process modules 226. As seen in Figure 4, these components may be operationally connected to one another and to secure solution 200, as well.

[0029] In operation, commands from the Human Machine Interface (HMI) 202, which may also be referred to as Industrial Control System (ICS) 202, are fed into an S- Tunnel port of secure solution 200. As those of skill are aware, S-Tunnel porting is the technique of entering a switch or hub at one port but reporting another port to the log.

[0030] Within the secure solution 200, a command from the HMI/ICS 202 is randomly encrypted (256-bit|512-bit) and 1 of 4 available transmission lines is selected at random to transmit the ICS command. Each of the 4 transmission lines is paired with one other transmission line. The randomly chosen transmission line transmits the command, and the transmission line paired to the randomly selected line transmits a signal comprising the inverse or bitwise logical NOT of the command signal. Simultaneously, the other pair of transmission lines transmit a false command signal and the inverse or bitwise logical NOT of the false command signal, respectively. All transmissions are executed concurrently, causing any monitoring device or software only to see a string of Os.

[ 0031 ] Within the secure solution 200, the two pairs of transmission lines enter a virtual VPN that is itself encapsulated within another virtual VPN.

[ 0032 ] The command from the HMI/ICS 202 and three read canceling fake commands exit the virtual VPN within a virtual VPN and are de-encrypted. Again going through an S- Tunnel port, the correct command is sent to controller 204, who, in turn, gives commands to actuators 224, which causes an industrial process 226 to proceed or cease. As an example, the command could turn a valve off or on, or start or stop a pump. Sensors 222 are responsible for reporting to controller 202 the current status of industrial process 226. Additional details of secure solution 200 are described below.

[ 0033 ] Figure 5 provides additional detail as to the secure solution 200 shown in Figure 4. As seen in Figure 5, secure solution includes a secure tunnel ("s-tunnel" or "stunnel") 250 at a first end, which is in direct operational communication with an encrypt/decrypt module 252 to encrypt signals 254, 256. Signals 254, 256, in turn, are transmitted within a first virtual private network (VPN) 258. First VPN 258 is transmitted within a second VPN 260. In other words, VPN 258 is a VPN within a VPN. Signals 262, 264 at the other end of VPN 258 are received and transmitted by encrypt/decrypt module 266, which is operationally connected to s-tunnel module 268. Together, encrypt/decrypt module 252, encrypt/decrypt module 266 and the operational elements therebetween form a secure communications core 270.

[ 0034 ] Figure 6 depicts additional operational details of secure communications core 270. As seen in Figure 6, an incoming bit pattern 256 is communicated to encrypt/decrypt module 252. The output from encrypt/decrypt module 252 comprises signal 254 and signal 256, which feed into transmission line module 274. Transmission line module 274 randomly selects a transmission line for transmission of signal 256. The output from transmission line module 274 feeds into binary generation engine 276 and transmission line module 288. A first signal 278 comprises a copy of the incoming signal 256, which is communicated directly to transmission line module 288. Signals 280, 282, 284 are communicated from binary generation engine 276 to binary generation engine 286.

[0035] Signal 280 comprises a binary logical NOT or inverse of signal 278. In other words, the state of each bit in signal 280 is the inverse of the corresponding bit in signal 278. Signal 282 is a false or "dummy" signal. In the embodiment shown in Figure 6, signal 282 is a pattern of alternating high and low bits, as an example. Signal 284 comprises a bitwise logical NOT or inverse of signal 282. Thus, in the embodiment shown in Figure 6, signal 284 is a pattern of alternating high and low bits in an inverse relationship to the pattern of signal 282. Signals 262,

264 from binary generation engine 286 and transmission line module 288 feed into encrypt/decrypt module 266, and the resultant signal 290 is communicated to an external node, such as s-tunnel module 268.

[0036] Figure 7 shows a site device 300 suitable for use in an industrial environment, to provide secure communication with an industrial device 306 over an untrusted network 302. Site device 300 incorporates internal computer 304 and internal router 310. Internal router 310 incorporates network interfaces 312, 314, 332, 334. Network interface

312 connects internal router 310 to untrusted network 302. Network interface 314 connects internal router 310 to network interface 316 of internal computer 304. In the embodiment shown in Figure 7, network interface 316 may be port 443 of internal computer 304.

[0037] Internal computer 304 incorporates a variety of operational modules, including network interface 316, stunnel server 318, port 320, VPN server 322, traffic obfuscation module 324, Tshark 328, internet protocol (IP) tables 328, and network interface 330. Stunnel server 318 connects network interface 316 to network interface 320. Stunnel server 318 provides authentication, HTTPS encryption and port redirection functionality. Port 320 (4430) connects stunnel server 318 to VPN server 322. VPN server 322 (TunO) is operationally connected to port 320, traffic obfuscation module 324, Tshark module 326 and internet protocol tables 328. VPN server 322 provides authentication and ECDSA encryption functionality.

[0038] Traffic obfuscation module 324 is operationally connected to VPN server 322 and Tshark 326. Traffic obfuscation module 324 calculates inverse SRC:DST and sends and receives pings based on data sent between the external node and industrial device 306, along with intermittent pseudorandom traffic. Tshark 328 captures live traffic on VPN server 322 (TunO) and feeds traffic data to traffic obfuscation script 324. IP tables 326 forward traffic between VPN server 322 (TunO) and network interface 330. Network interface 330 handles traffic between internal computer 304 and network interface 332 of internal router 310.

[0039] Within internal router 310, network interface 332 serves as a relay between network interface 330 of internal computer 304 and network interface 334. Network interface 334, in turn, serves as an interface between network interface 332 and network interface 336 for device 306.

[0040] The functionality of device 300 can be observed in connection with signal 340 transmitted from device 306. Signal 340 is passed from device 306 by network interface 336, into internal router 310 via network interface 334. Signal 340 is then passed along from internal router 310 to internal computer 304 via network interfaces 332, 330.

[0041] Within internal computer 304, signal 340 passes from network interface 330 to VPN server 322 via IP tables 328. Tshark 326 captures at least a portion of signal 340 passing into VPN server 322, and feeds resultant data to traffic obfuscation module 324. Based on the data received from Tshark 326, traffic obfuscation module 324 generates an obfuscation signal 342, which is fed into VPN server 322 and transmitted alongside signal 340 to stunnel server 318 via network interface 320.

[0042] Signals 340, 342 from network interface 320 are transmitted from VPN server 318 to network interface 316 within a VPN tunnel 344. Signals 340, 342 are then transmitted from internal computer 304 to internal router 310 within stunnel HTTPS tunnel 346 via network interfaces 316, 314. Signals 340, 342 within VPN tunnel 344 and stunnel 346 are then communicated from internal router 310 across untrusted network 302 via network interface 312.

[0043] Figure 8 shows a human machine interface (HMI) client 400 according to certain embodiments of the present disclosure. Client 400 includes computer 402 running human machine interface software 404 and connected to display 406. Client 400 further includes certain operational components to facilitate secure communication across untrusted network 408, including VPN client 410 receiving unencrypted traffic 412, ping package 414 generating obfuscation traffic 416, port 418 maintaining VPN tunnel 420, stunnel client 422 and network interface 424 maintaining stunnel HTTPS tunnel 426.

[0044] VPN client 410 provides authentication and ECDSA encryption. Ping package 414 responds to obfuscation module ping requests and makes traffic appear legitimate when observed outside the secure tunnels. Port 418 serves as an entry to stunnel client 422. Stunnel client 422 provides authentication, HTTPS encryption and port redirection .

[0045] The process flow of one embodiment of the secure solution is shown in additional detail in Figures 9A and 9B. Process flow begins at 450 and proceeds to step 452.

In step 452, a local HMI computer is booted up. In step 454, a local VPN client sends a request to establish a secure tunnel on a local host port routed to a Local Stunnel Client. In step 456, the Local Stunnel Client captures request on a local port. In step 458, the Local Stunnel Client wraps the VPN Request with a Stunnel HTTPS Client Request. In step 460, the Local Stunnel Client sends the bundled request to a remote device. In step 462, an Internal Router of the Remote Device receives the Bundled Request. In step 464, the Internal Router redirects the Request to an Internal Computer. In step 466, NIC 2 of Internal Router Send Bundled Request to NIC 2 of Internal Computer on Port 443. In step 468, NIC 2 of Internal Computer routes Bundled Request to Stunnel Server for authentication, and process flow proceeds to step 470 of Figure 9B.

[0046] In step 470, it is determined whether the Stunnel Certificate is authorized to connect. If the Stunnel Certificate is not authorized to connect, process flow proceeds to 472, where the Stunnel Request is dropped and a VPN Error is sent to the HMI Computer. If the Stunnel Certificate is authorized to connect, process flow proceeds to 474, where the Stunnel Request is decrypted. In step 476, the Request is routed to an Internal VPN Server Port. In step 478, it is determined whether the VPN Certificate is authorized to connect. If the VPN Certificate is not authorized to connect, process flow proceeds to step 480, where the VPN Request is dropped and a VPN error is sent to the HMI Computer. If the VPN Certificate is authorized to connect, the VPN Request is decrypted in step 482. In step 484, the VPN Request is routed to NIC 3. In step 486, the VPN Tunnel within the Stunnel Tunnel is now established.

In step 488, the Traffic Obfuscation Script immediately starts sending psuedo-random and calculated false data through the Tunnel. Local operators of the HMI computer may now send monitoring and operation instructions to the Remote Device at the Remote Site through the authenticated, encrypted, and obfuscated Tunnel.

[ 0047 ] The disclosure has been described above in connection with certain specific embodiments of the inventive concepts. It should be apparent to those skilled in the art that many more modifications besides those already described are possible without departing from the inventive concepts herein. The inventive subject matter, therefore, is not to be restricted except in the spirit of the appended claims. Moreover, in interpreting both the specification and the claims, all terms should be interpreted in the broadest possible manner consistent with the context. In particular, the terms "comprises" and "comprising" should be interpreted as referring to elements, components, or steps in a non-exclusive manner, indicating that the referenced elements, components, or steps may be present, or utilized, or combined with other elements, components, or steps that are not expressly referenced. Where the specification claims refers to at least one of something selected from the group consisting of A, B, C .... and N, the text should be interpreted as requiring only one element from the group, not A plus N, or

B plus N, etc.

Claims

CLAIMS What is claimed is:

1. A system for secure communication between a first node and a second node, the system comprising: a first secure tunnel module disposed at a first end of a communications channel; a second secure tunnel module disposed at a second end of a communications channel; a first virtual private network having a first end and a second end, disposed between the first secure tunnel module and the second secure tunnel module; and a second virtual private network disposed between the first end and second end of the first virtual private network.