Patent Description:
Therefore, the approaches described in this section may not be prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.

When information must be transferred between isolated networks of differing confidentiality or integrity, existing information security models (e.g., Bell-LaPadula and Biba) favor implementation of one-way information flow controls. Examples include: (i) ingest of business intelligence and military intelligence information into confidential networks where backward flow is considered breach of secrecy; and (ii) release of real-time state information from a high-integrity Industrial Control System (ICS) networks for purposes of remote monitoring where ingress of malicious software could disable operations. Examples of the latter include Industrial Control System (ICS) networks in nuclear power plants.

Information flow control may be implemented in software or hardware. However, software is known to be vulnerable to various forms of software attack, which makes hardware-enforced flow control more attractive because unauthorized reconfiguration of the security device cannot be achieved without physical access to the device.

For some high-impact sectors of the US designated as "critical infrastructure" and defined accordingly by the Department of Homeland Security, implementation of hardware-enforced, one-way information flow control devices to protect critical networks are now required by law. One example of "critical infrastructure" sector is the US nuclear industry.

The US National Institute of Standards and Technology (NIST) defines an explicit security control (information security risk mitigation method) in <NPL>), <NPL>.

Historically, one-way information flow control devices, also known as "data diodes," have been unreliable, slow, difficult to configure (and thus prone to user error), and/or very expensive, and few vendors offer one-way information flow control products. The majority of one-way information flow control products were implemented in software, typically by implementing network access restrictions in commercial firewalls from vendors such as Cisco™ and Sidewinder™. Some specialty one-way information flow control devices, e.g., those produced by Tresys™, implement software that is secured using SE Linux security policies. However, even those software products implementing rigorous security enhancements are known to be vulnerable to a broad variety of software attack methods.

Hardware-enforced one-way information flow control devices are more secure than software-based products because the hardware-enforced configuration cannot be altered by software attack, and their inherent security cannot be breached without physical access. However, conventional hardware-enforced one-way flow control has proven to be problematic for a variety of reasons. One problem has been very slow speed, e.g., as implemented in RS-<NUM> cables with one wire clipped. The US Naval Research Laboratory produced a data diode called the Network Pump that is known to be very slow and is not purely one-way in its information flow. The Network Pump presents a reverse information flow acknowledgement of limited bandwidth. Another problem has been unreliable performance, e.g., as implemented with dubious protocol compromises or with many critical components whose combined MTBF (mean time between failure) results in short overall lifespan. Yet another problem has been the high cost, e.g., as implemented using ATM IC (asynchronous transfer mode integrated circuit) components or custom FPGA (field-programmable gate array) devices by Owl Computing Technologies™. <CIT> discloses a one-way information flow control device comprising: a first network interface card on a transmission side, the first network interface card including a first transceiver having a transmit port; a second network interface card on a receiving side, the second network interface card including at least one receive port; a third data connection segment connecting the first transceiver transmit port to the receive port of the second network interface card. <CIT> discloses an apparatus for relaying a hashed message from a first node to a second node, comprising an inlet interface for receiving a message from the first node, a hash number calculator for hashing the message from the inlet interface, an outlet interface for sending the hashed message to the second node, a first one-way data link for unidirectional transfer from the inlet interface to the hash number calculator, and a second one-way data link for unidirectional transfer from the hash number calculator to the outlet interface. The apparatus provides a secure mechanism and communication channel for relaying hashed acknowledgement messages from a receive node to a send node to inform the status of data transfer.

In view of the prior art cited above, there exists a need for an improved hardware-enforced one-way information flow control device.

The present disclosure is directed to implementing one-way information flow control using a hardware-enforced one-way information flow control device or system.

Information flows from an information-source computer platform into the hardware-enforced one-way information flow control device or system of the present disclosure through a standard network socket interface software. Subsequently, the information is routed within the transmission side of the one-way information flow control device through a proprietary software interface to an opto-electronic hardware in the transmission side, followed by transmission via an optical physical transmission medium to an opto-electronic hardware on the receiving side of the one-way information flow control device or system. The information is routed within the receiving side from the opto-electronic hardware through a proprietary software interface, followed by outward flow of information from the receiving side of the one-way information flow control device or system through standard network socket interface software.

Specific examples of information flow that may benefit from the hardware-enforced one-way information flow control device or system of the present disclosure include security video camera information feeds (e.g., Moving Picture Experts Group transport stream (MPEG-TS)), audio communications (MPEG audio), inter-computer error alert messages (e.g., Simple Network Management Protocol (SNMP) and Syslog (message logging standard) messages). These information flows may be rendered, e.g., as streams of User Datagram Protocol (UDP) Datagrams that travel across networks with minimal latency. No feedback or acknowledgement is required. UDP multicasting may be used in Industrial Control System (ICS) network for implicit messages that are most critical and for real-time communications. UDP Datagrams may also be used to transmit real-time state information relating to physical objects, e.g., pumps, furnaces, and generators. Information from such computer controlled physical objects may include temperature, pressure, alarms, and alerts as implemented in nuclear power plants. Nuclear Regulatory Commission Guidance document NRG <NUM> mandates use of one-way information flow control devices to protect the innermost (i.e., highest impact) Critical Cyber Assets in nuclear ICS networks. As illustrated in detail in <FIG>, which shows layered network security in nuclear power plants mandated by the U. Nuclear Regulatory Commission Guidance NRG <NUM>, physical Critical Cyber Assets are located on the NRC Level <NUM> ICS Network, and may be monitored from external network locations anywhere.

In an example embodiment, the one-way information flow control device or system may include: (i) a pair of optical network interface cards (a sending network interface card (SNIC) and a receiving network interface card (RNIC)), which are connected by at least one Y-configuration split optical fiber and a standard optical fiber; and (ii) software integrated to transfer data in one-direction from the SNIC to the RNIC without any backward flow of information, without any electrically conductive connection, and without the use of a routable communication protocol. SNIC and RNIC are typically installed in physically separate computer platforms. In other embodiments, one or both of the SNIC and RNIC may be connected to computer platforms. Instead of optical fibers, the one-way information flow control device or system may be configured such that Ethernet cables or other transmission cables connect the SNIC to the RNIC. Attentively, the SNIC and RNIC may be connected wirelessly.

In an example embodiment, the SNIC may include two bi-directional optical transceivers and the RNIC may include one bi-directional optical transceiver. In another example embodiment, the SNIC may include two bi-directional optical transceivers and the RNIC may include two bi-directional optical transceivers.

In another example embodiment, when the sending network interface card (SNIC) and two receiving network interface cards (RNICs) are installed in physically separate computing platforms, the one-way information flow control device or system according to the present disclosure permits one computing platform to send information to the two other computing platforms while not permitting any information to flow in the reverse direction and while all computing platforms remain electrically isolated from each other. In other embodiments, one or more of the SNIC and the two RNICs may be connected to computer platforms. For example, the two RNICs may be connected to the same computer platform or to separate computer platforms.

The hardware-enforced one-way information flow control device or system according to the present disclosure provides numerous desirable features and advantages: high data transfer throughput; low data transfer latency; inherent simplicity that does not rely on custom IC (integrated circuit) hardware or FPGA (field-programmable gate array) devices; inherent reliability resulting from simplicity; multiple independent streams of information may flow through the device concurrently; and standard socket interfaces may be used to pass information to and from the device.

A component or a feature that is common to more than one drawing is indicated with the same reference number in each of the drawings.

<FIG> shows an illustrative example of a one-way information flow pipeline implemented with a hardware-enforced one-way information flow control device or system <NUM> which facilitates a one-way flow of information (represented by arrow <NUM>) between an isolated Industrial Control System (ICS) network <NUM> and a public access network <NUM>, which public access network <NUM> in turn provides the information to an information destination <NUM>. One-way information flow prevents malware from entering the ICS network <NUM> and permits remote monitoring at the information destination <NUM> while maintaining network isolation of the ICS network <NUM>. In the example shown in <FIG>, the ICS network <NUM> includes, e.g., information sources <NUM> of a nuclear reactor system <NUM>, sensors and/or monitoring device <NUM>, and industrial controllers <NUM>. Information sources <NUM> may include, e.g., components of reactor vessels, pumps, valves, and turbines. Sensors and monitoring devices <NUM> obtain real-time data (e. g, pressure, temperature, turbine speed, etc.) from the information sources <NUM> and transmit the real-time data to the industrial controllers <NUM> for processing and further action. The real-time data from industrial controllers <NUM> of the isolated ICS network <NUM> may be provided to the information destination <NUM> in a one-way information flow <NUM> via the hardware-enforced one-way information flow control device or system <NUM>, thereby enabling personnel at the information destination <NUM> (which may be, e.g., a remote management site) to have detailed, real-time information regarding the nuclear reactor system <NUM>.

<FIG> shows an illustrative example of an information security environment mandated by regulatory guidelines, which information security environment may be achieved with the aid of a hardware-enforced one-way information flow control device or system according to the present disclosure. More specifically, <FIG> shows layered network security in nuclear power plants mandated by the U. Nuclear Regulatory Commission Guidance NRG <NUM>, according to which regulatory framework four separate levels of ICS networks are provided. Information sources <NUM> of a nuclear reactor system <NUM> are provided within NRC Level <NUM> ICS network 101a, and mandated one-way information flow 109a from NRC Level <NUM> ICS network 101a to NRC Level <NUM> ICS network 101b may be enforced by a one-way information flow control device 100a. Similarly, mandated one-way information flow from NRC Level <NUM> ICS network 101b to NRC Level <NUM> ICS network 101c may be enforced by a one-way information flow control device 100b. Information flow between NRC Level <NUM> ICS network 101c and NRC Level <NUM> ICS network 101d may be bi-directional information flow via controlled interface network security device 110a. In addition, bi-directional information flow between NRC Level <NUM> ICS network 101d and information destination <NUM> (e.g., a remote management site) staffed by personnel <NUM> may be achieved via controlled interface network security device 110b and Internet <NUM>.

<FIG> shows an illustrative example of an information security environment implementing information confidentiality flow policy restrictions, which information security environment may be achieved with the aid of a hardware-enforced one-way information flow control device or system according to the present disclosure. Some examples of information confidentiality flow policy restrictions include restrictions related to military operations, civilian emergency response operations, and some business operations. For implementing information confidentiality flow policy restrictions between a low-confidentiality domain (e.g., the domain of public access network <NUM>) and a high-confidentiality domain (e.g., the domain of confidential network <NUM>), separate one-way information flow control devices 100c and 100d may be utilized.

Information gathered by sensors and/or monitoring devices <NUM> and/or information from researchers, data gatherers and/or witnesses 109a, may be sent from the domain of public access network <NUM> to the domain of confidential network <NUM> (which is accessible by personnel 109b such as executives, commanders, and decision makers are present) via a one-way information flow control device 100c, with a scan 203a for malware contamination being performed so as to prevent any malware <NUM> entering the confidential network <NUM>. The scan 203a for malware contamination maintains integrity of information in the domain of confidential network <NUM>. The scan 203a may be performed by the one-way information flow control device 100c or by a separate scanning device.

Information from the confidential network <NUM>, e.g., information released by personnel 109b such as executives, commanders, decision makers, etc., is subjected to scan 203b for approval signature for release, and if the approval signature for release is present, transmitted via the one-way information flow control device 100d to the domain of the public access network <NUM>, within which the transmitted information may be delivered to the control devices <NUM> and/or recipients 109c, e.g., troops, emergency response personnel, and field personnel. The scan 203b for approval signature for release prevents unintentional disclosure of restricted information. Furthermore, the one-way information flow control device 100d prevents any malware <NUM> from entering the confidential network <NUM> from the public access network <NUM>.

<FIG> shows example hardware and software components of an illustrative example embodiment of a hardware-enforced one-way information flow control device or system <NUM>, the boundary of which device or system <NUM> is shown by the dashed line. Information flows from an information source <NUM>, e.g., a computer platform, through a standard network interface (e.g., hardware (HW) interface <NUM>, which may be RJ45 interface, and network interface card (NIC) <NUM>) into inlet host computer platform <NUM>, to which the "sending" side of the hardware-enforced one-way information flow control device or system <NUM> is linked. A proprietary software interface <NUM> (designated herein as "Relay UDP to Frame Interfacing Software" in <FIG>, but also referred to as "SNIC Interfacing Software" in the present disclosure) opens a raw output (sending) socket that binds to an optical sending network interface card (SNIC) <NUM> within the "sending" side of the one-way information flow control device or system <NUM>. The SNIC <NUM> may be, e.g., a <NUM> (gigabit) SNIC. The software interface <NUM> receives information from the inlet host computer platform <NUM> via a standard UDP Datagram receiving socket <NUM> and/or other standard programming interface methods such as file resource access (the example embodiment of the one-way information flow control device or system <NUM> is not limited to these interface methods which are merely examples, and hence UDP and file resource access may be seen as examples of more general "data outlet interface"), and routes the information within the "sending" side of the one-way information flow control device or system <NUM> to a primary optical transceiver device <NUM> of an optical sending network interface card (SNIC) <NUM> which utilizes, e.g., PCle (peripheral component interconnect express) expansion bus standard shown as box <NUM> in <FIG>. As is widely understood by one of ordinary skill in the art, a "socket" as used in the present disclosure (e.g., UDP sockets <NUM> and <NUM>) refers to a software element in networking software (e.g., protocol stack), which "socket" represents an internal endpoint for sending or receiving data at a single node in a computer network. The information is transmitted from the primary optical transceiver device <NUM> of the SNIC <NUM> to a primary optical transceiver device <NUM> of an optical receiving network interface card (RNIC) <NUM> on the "receiving" side of the hardware-enforced one-way information flow control device or system <NUM> via a fiber-optic connection arrangement which is described in further detail below.

Within the receiving side of the hardware-enforced one-way information flow control device or system <NUM>, a proprietary software interface <NUM> (designated as "Relay Frame to UDP Interfacing Software" in <FIG>, but also referred to as "RNIC Interfacing Software" in the present disclosure) opens a raw receiving (input) socket that binds to an optical receiving network interface card (RNIC) <NUM>. The RNIC <NUM> may be, e.g., a <NUM> (gigabit) RNIC. The software interface <NUM> routes the information from the primary optical transceiver device <NUM> of the RNIC <NUM> which utilizes, e.g., PCle (peripheral component interconnect express) expansion bus standard shown as box <NUM> in <FIG>, to a network interface card (NIC) <NUM> via a UDP Datagram sending socket <NUM> and/or other standard programming interface methods such as file resource access. The information is routed from the NIC <NUM> to the information destination <NUM> (e.g., a computer platform) through a standard network interface hardware, e.g., hardware (HW) interface <NUM>, which may be RJ45 interface.

The fiber-optic connection linking various parts of the SNIC <NUM> and the RNIC <NUM> shown in <FIG> is described in further detail here. The SNIC <NUM> provides two bi-directional optical interfaces: primary optical transceiver device <NUM>; and secondary optical transceiver device <NUM>. Primary optical transceiver device <NUM> and secondary optical transceiver device <NUM> each include an optical emitter port (TX) and an optical detector (receiver) port (RX). A split optical fiber <NUM> (e.g., Lucent™ connector (LC) type) having a Y-shape is provided, with the fused end of the split optical fiber <NUM> (the trunk of the Y) inserted into the TX port of the SNIC primary optical transceiver device <NUM>. One of the remaining ends of the split optical fiber <NUM> is inserted into the RX port of the SNIC secondary optical transceiver device <NUM>. The remaining end of the split optical fiber <NUM> is inserted into the RX port of the primary optical transceiver device <NUM> in the RNIC <NUM>. A standard optical fiber <NUM> connects the TX port of the SNIC secondary optical transceiver device <NUM> to the RX port of the SNIC primary optical transceiver device <NUM>. The fiber-optic connection between the primary and secondary optical transceiver devices <NUM> and <NUM> provided by the optical fibers <NUM> and <NUM> permits the primary and secondary optical transceiver devices <NUM> and <NUM> to sense a datalink connection. The TX port of the RNIC primary optical transceiver device <NUM> is disabled or plugged, e.g., with optically opaque material. In some embodiments, the primary optical transceiver device <NUM> in the RNIC <NUM> has an RX port only, i.e., it does not have a TX port. The fiber-optic connection arrangement provided by the optical fiber <NUM> between the primary optical transceiver device <NUM> of SNIC <NUM> and the primary optical transceiver device <NUM> of RNIC <NUM> permits the RNIC <NUM> to sense a datalink connection, but the RNIC <NUM> cannot transmit any information due to the plugging of the TX port of the primary optical transceiver device <NUM>, and therefore the RNIC <NUM> functions as an optical tap that only receives information in a one-way information transfer across the network isolation boundary <NUM> shown in <FIG>, i.e., via the portion of the optical fiber <NUM> linking the TX port of the primary optical transceiver device <NUM> in the SNIC <NUM> to the RX port of the primary optical transceiver device <NUM> in the RNIC <NUM>.

In some embodiments, a single connector provides for both the emitter port (TX) and the receiver port (RX). In other embodiments, the emitter port (TX) and the receiver port (RX) are provided by two separate connectors in the transceiver. Although the one-way information flow control device or system <NUM> is described above as comprising optical network interface cards, it may be configured to have Ethernet cards, wireless cards, modem cards, or other types of network interface cards. Furthermore, the one-way information flow control device or system may utilize different types of network interface cards in order to provide the connections between the transmission side and the receiving side.

A brief discussion of commercial off-the-shelf (COTS) network interface cards (NICs) operation is provided here to explain the interaction between SNIC <NUM> and RNIC <NUM>. COTS NICs present specific hardware features that indicate certain conditions, e.g., LED link light, which indicates whether a network connection exists between the NIC and the network. For example, an unlit LED link light is an indication that something is awry with the network cable or connection. NIC hardware will not send information on command if a valid network link is not detected (which network link detection requires a certain amount of information to be received by the NIC), and network link connectivity to be detected by NIC hardware cannot be configured in software.

For the foregoing reason, in the one-way information flow control device or system <NUM> according to the present disclosure, the secondary send-side transceiver (e.g., transceiver device <NUM> in <FIG>) is provided to generate a network link that results in an indication of message traffic to the primary send-side transceiver (e.g., transceiver device <NUM> in <FIG>). Using the split optical fiber <NUM>, the primary send-side transceiver (e.g., transceiver device <NUM> in <FIG>) also sends enough information for the primary receive-side transceiver (e.g., transceiver device <NUM>) to detect a valid network link. When the secondary send-side transceiver (e.g., transceiver device <NUM> in <FIG>) is connected to enable bi-directional communication with the primary send-side transceiver (e.g., transceiver device <NUM> in <FIG>), the primary send-side transceiver detects a valid network link, and the primary send-side transceiver will send information on command when the valid network link is detected. When information is sent from the primary send-side transceiver (e.g., transceiver device <NUM> in <FIG>), it is sent to two destinations through the split optical fiber (e.g., optical fiber <NUM>): the secondary send-side transceiver (e.g., transceiver device <NUM>) and the primary receive-side transceiver (e.g., transceiver device <NUM>). Since the information sent by the primary send-side transceiver (e.g., transceiver device <NUM> in <FIG>) in the one-way information flow control device or system <NUM> according to the present disclosure is, by design, specifically addressed (e.g., using MAC (media access control) address) to the primary receive-side transceiver (e.g., transceiver device <NUM>), the sent information is ignored by the secondary send-side transceiver (e.g., transceiver device <NUM>).

<FIG> shows illustrates the core concept of how a pair of standard hardware-implemented two-way communication optical network interface cards are transformed into a specialized hardware-enforced one-way information flow control device by connecting the optical network interface cards using a split optical fiber arrangement.

<FIG> shows example hardware and software components of another illustrative example embodiment of a hardware-enforced one-way information flow control device or system <NUM>, the boundary of which device or system <NUM> is shown by the dashed line. The example embodiment shown in <FIG> is substantially similar to the example embodiment shown in <FIG>, with the following differences: (i) in <FIG>, multiple network interface cards (NIC) <NUM> are provided in each of the inlet host computer platform <NUM> and outlet host computer platform <NUM>; (ii) in <FIG>, a secondary optical transceiver device <NUM> is additionally provided in the RNIC <NUM>; and (iii) instead of the connection provided by the optical fiber <NUM> in <FIG>, a split optical fiber <NUM> (e.g., Lucent™ connector (LC) type) having a Y-shape is provided. The software interface <NUM> receives information from the inlet host computer platform <NUM> via a standard UDP Datagram receiving socket <NUM> and/or other standard programming interface methods such as file resource access, and routes the information within the "sending" side of the one-way information flow control device or system <NUM> to the primary optical transceiver device <NUM> and the secondary optical transceiver device <NUM> of the SNIC <NUM>. The information is transmitted from the primary and secondary optical transceiver devices <NUM> and <NUM> of the SNIC <NUM> to the primary and secondary optical transceiver devices <NUM> and <NUM> of the RNIC <NUM>, respectively, via a fiber-optic connection arrangement which is described in further detail below. Within the receiving side of the hardware-enforced one-way information flow control device or system <NUM>, the software interface <NUM> routes the information from the primary and secondary optical transceiver devices <NUM> and <NUM> of the RNIC <NUM> to a network interface card (NIC) <NUM> via a UDP Datagram sending socket <NUM> and/or other standard programming interface methods such as file resource access. The information is routed from the NIC <NUM> to the information destination <NUM> (e.g., a computer platform) through a standard network interface hardware, e.g., hardware (HW) interface <NUM>, which may be RJ45 interface.

The fiber-optic connection linking various parts of the SNIC <NUM> and the RNIC <NUM> shown in <FIG> is described in further detail here. The fiber-optic connection among the transceiver devices <NUM>, <NUM> and <NUM> using the split optical fiber <NUM> in <FIG> corresponds to the connection shown in <FIG>. In addition, a split optical fiber <NUM> (e.g., Lucent™ connector (LC) type) having a Y-shape is provided, with the fused end of the split optical fiber <NUM> (the trunk of the Y) inserted into the TX port of the SNIC secondary optical transceiver device <NUM>. One of the remaining ends of the split optical fiber <NUM> is inserted into the RX port of the SNIC primary optical transceiver device <NUM>. The remaining end of the split optical fiber <NUM> is inserted into the RX port of the secondary optical transceiver device <NUM> in the RNIC <NUM>. The TX ports of the RNIC primary and secondary optical transceiver devices <NUM> and <NUM> are plugged, e.g., with optically opaque material. The fiber-optic connection arrangement provided by the portion of the optical fiber <NUM> between the primary optical transceiver device <NUM> of SNIC <NUM> and the primary optical transceiver device <NUM> of RNIC <NUM> permits the transceiver device <NUM> of the RNIC <NUM> to sense a datalink connection, but the transceiver device <NUM> of the RNIC <NUM> cannot transmit any information due to the plugging of the TX port of the transceiver device <NUM>. Similarly, the fiber-optic connection arrangement provided by the portion of the optical fiber <NUM> between the secondary optical transceiver device <NUM> of SNIC <NUM> and the secondary optical transceiver device <NUM> of RNIC <NUM> permits the transceiver device <NUM> of the RNIC <NUM> to sense a datalink connection, but the transceiver device <NUM> of the RNIC <NUM> cannot transmit any information due to the plugging of the TX port of the transceiver device <NUM>. In this manner, the RNIC <NUM> functions as an optical tap that only receives information in a one-way information transfer across the network isolation boundary <NUM> shown in <FIG>, i.e., via the portions of the optical fibers <NUM> and <NUM> linking the TX ports of the primary and secondary optical transceiver devices <NUM> and <NUM> in the SNIC <NUM> to the RX ports of the primary and secondary optical transceiver devices <NUM> and <NUM> in the RNIC <NUM>, respectively.

<FIG> shows example hardware and software components of another illustrative example embodiment of a hardware-enforced one-way information flow control device or system <NUM>, the boundary of which device or system <NUM> is shown by the dashed line. The example embodiment shown in <FIG> is substantially similar to the example embodiment shown in <FIG>, with the difference that the embodiment of <FIG> comprises an independent proprietary software module driving each optical transceiver in the SNIC and in the RNIC. In the example embodiment of <FIG>, the independent software modules may be optimized for different IP protocols (e.g., UDP and TCP), may be prioritized at different levels by the host operating system, and may be assigned to different CPU cores for accelerated (e.g., parallel) processing. In the example shown in <FIG>, the P1P1 transceiver driver module may be configured, e.g., to receive UDP packets, which requires high prioritization in order to prevent UDP packets from being dropped at the receiving socket (because delivery of UDP packet transfer is session-less and delivery of the UDP packets is not assured by the protocol specification). The P1P2 transceiver driver module may be configured, e.g., for TCP sessions, and may run at much lower priority in the host operating system (because the TCP protocol is session-based and delivery of TCP packets is assured by the protocol specification). Running two concurrent software processes at different priority levels assures that the UDP packets will be captured and processed with high priority (protecting against packet loss) while concurrently assuring that TCP sessions (which may be encrypted and may significantly load the CPU) operate in the background self-modulating their information transfer rates at lower priority without data loss.

<FIG> shows example hardware and software components of another illustrative example embodiment of a hardware-enforced one-way information flow control device or system <NUM>, the boundary of which device or system <NUM> is shown by the dashed line. The example embodiment shown in <FIG> is substantially similar to the example embodiment shown in <FIG>, with the difference that in the embodiment of <FIG>, the two optical fiber connections from a single SNIC are connected to two different outlet computer platforms, e.g., platform A and platform B, each equipped with an RNIC but otherwise isolated from each other. Due to the one-way information flow into each RNIC, the two RNIC host computer platforms A and B present total network isolation from each other. This configuration solves a significant problem in Cross Domain connectivity, i.e., it is sometimes desirable to connect a single source to multiple recipient destinations while ensuring that the recipient destinations cannot communicate with one-another.

<FIG> shows an example expansion of the configuration illustrated in <FIG>. In the arrangement shown in <FIG>, information flows from a source to multiple recipient destinations present complete network isolation from one-another, and the fan-like flow of information may be extended to an arbitrarily large number of recipients.

<FIG> shows an example expansion of the configuration illustrated in <FIG>. In the arrangement shown in <FIG>, information flows from a source to multiple recipient destinations include additional split fibers that create fan-like flow of duplicate information through multiple, redundant data paths; which may be extended to an arbitrarily large number of recipients.

<FIG> shows an illustration of an example logic flow <NUM> implemented by the interfacing software <NUM> (on the "sending" side of the one-way information flow control device or system <NUM>) and the interfacing software <NUM> (on the "receiving" side of the one-way information flow control device or system <NUM>) in conjunction with the optical hardware elements (e.g., SNIC <NUM>, RNIC <NUM>, and the optical fibers <NUM>, <NUM> and <NUM> shown in <FIG> and <FIG>) for achieving the one-way information flow according to the present disclosure. Logic blocks <NUM> through <NUM> are implemented by the interfacing software <NUM>. In the logic block <NUM>, the interfacing software <NUM> opens a raw output (sending) socket for sending, e.g., Ethernet, frames. In the logic block <NUM>, the interfacing software <NUM> binds the output (sending) socket to the optical output device, e.g., optical sending network interface card (SNIC) <NUM>. In the logic block <NUM>, the interfacing software <NUM> opens an inlet datagram socket for receiving datagram(s), e.g., UDP datagram socket (corresponding to UDP socket <NUM> shown in <FIG> and <FIG>), and in the logic block <NUM>, datagram (e.g., UDP datagram in Dataflow A portion) from the information source <NUM> is received at the inlet datagram socket. Subsequently, the received datagram packet is screened and the payload portion is extracted in the logic block <NUM>, followed by the logic block <NUM> in which the extracted payload is inspected and filtered (if necessary), as well as optionally adding (if required) lane ID based on inlet port (the lane ID implementation will be explained in further detail below). Data filters may be invoked by the interfacing software <NUM> if additional constraints on forward information flow are desirable, e.g., making forward transfer of payload conditional on conformance of payload data to a specific protocol (such as MPEG-TS (MPEG transport stream) protocol, for example). In the logic block <NUM>, the interfacing software <NUM> constructs an Ethernet frame around the payload destined for the hardware address of the RNIC <NUM> (the Ethernet frame structure and the nesting of UDP packets within IP packets and Ethernet frames will be explained in further detail below). In the logic block <NUM>, the Ethernet frame is sent to the output device (e.g., the SNIC <NUM> in <FIG> and <FIG>), from which the Ethernet frame is transmitted (see Dataflow B portion) to the RNIC <NUM> (using the media access control (MAC) address of the receiving transceiver device <NUM> and/or <NUM>) on the receiving side where the interfacing software <NUM> implements logic blocks <NUM> through <NUM>.

In the logic block <NUM>, the interfacing software <NUM> opens a raw input (receiving) socket for receiving, e.g., Ethernet, frames. In the logic block <NUM>, the interfacing software <NUM> binds the input (receiving) socket to the optical input device, e.g., optical receiving network interface card (SNIC) <NUM>. In the logic block <NUM>, the interfacing software <NUM> opens an outlet datagram socket for sending datagram(s), e.g., UDP datagram socket (corresponding to UDP socket <NUM> shown in <FIG> and <FIG>). In the logic block <NUM>, the Ethernet frame (e.g., in Dataflow B portion) from the "sending" side of the one-way information flow control device or system <NUM> is received at the RNIC <NUM>, which received Ethernet frame may be screened, e.g., by Ethertype and the hardware address. In the logic block <NUM>, the payload portion is extracted from the Ethernet frame, followed by the logic block <NUM> in which the payload is inspected and filtered (if necessary). Data filters may be invoked by the interfacing software <NUM> if additional constraints on forward information flow are desirable, e.g., making forward transfer of payload conditional on conformance of payload data to a specific protocol (such as MPEG-TS, for example). In the logic block <NUM>, the payload is encapsulated in a datagram, e.g., UDP datagram, for transmission to a destination (the destination may be set based on lane ID, if lane ID is used). In the logic block <NUM>, the datagram is sent (Dataflow C portion) to the information destination <NUM>, e.g., via the UDP socket <NUM>.

<FIG> shows an example layer stack which illustrates nesting of UDP packets within IP (Internet Protocol) packets and Ethernet frames in accordance with Transmission Control Protocol/Internet Protocol (TCP/IP) communication model (although the discussion here regarding the layer stack of TCP/IP may be applied to a simplified layer stack of Open System Interconnection (OSI) model). TCP/IP is a layered protocol, according to which transmitting software gives the data to be transmitted to the application layer, where the data is processed and subsequently passed from layer to layer down the layer stack, with each layer performing its assigned functions. As the data is passed through the layer stack, each layer adds a header to the data that directs and identifies the packet, which process is called encapsulation. The header and data together form the data packet for the next layer that, in turn, adds its header, and the process is repeated through the layer stack, until the combined encapsulated data packet is finally transmitted over the physical layer of the network to the destination device. The receiving device's software reverses the process, de-encapsulating the data at each layer as the data is passed up through the layers of the layer stack, with each layer performing its assigned operations until the data is ready for use by the receiving device's software.

As shown in <FIG>, the layer stack according to TCP/IP model has four layers: application layer <NUM>; transport layer <NUM>; Internet (IP) layer <NUM>; and link layer <NUM>. In the application layer <NUM>, applications (or processes) generate user data and communicate the data to other applications, e.g., on the same host or on another host. The applications (or processes) make use of the services provided by the lower layers, e.g., the transport layer <NUM>, which provides "pipes" to other processes that are addressed via ports which essentially represent services. Higher-level protocols, e.g., HTTP (Hypertext Transfer Protocol), SMTP (Simple Mail Transfer Protocol), FTP (File Transfer Protocol), and SSH (Secure Shell), operate in the application layer <NUM>. The transport layer <NUM>, which performs host-to-host communications, provides a channel for the communication needs of applications. In the example shown in <FIG>, UDP is the example protocol used for the transport layer <NUM>. The internet layer <NUM>, which performs the task of exchanging datagrams across network boundaries, defines the addressing and routing structures used for the TCP/IP protocol suite. Example protocols used in the internet layer <NUM> are Internet Protocol (IP) and ARP (Address Resolution Protocol). It should be noted that in the hardware-enforced one-way information flow control device or system <NUM> according to the present disclosure, IP and ARP protocols are not required and are not used for the communication between the SNIC <NUM> and the RNIC <NUM>. The link layer (or network access layer) <NUM> defines details of how data is physically sent through the network, including how bits are electrically or optically signaled by hardware devices that interface directly with a network medium, e.g., optical fibers or twisted pair copper wire. An example protocol used for the link layer <NUM> is Ethernet, a generalized frame structure for which is shown in <FIG>.

As mentioned above, SNIC interfacing software <NUM> receives data through standard UDP datagram receiving sockets (e.g., UDP socket <NUM> shown in <FIG> and <FIG>). <FIG> illustrates an example UDP datagram format, which includes the UDP header <NUM> and the UDP payload <NUM>. The UDP header <NUM> consists of <NUM> bytes and includes the following fields: source port (2bytes); destination port (<NUM> bytes); length (<NUM> bytes); and checksum (<NUM> bytes). The remaining bytes of the UDP datagram form the UDP payload <NUM>.

The term "port" used in the context of the UDP datagram shown in <FIG> should be distinguished from the hardware ports (e.g., TX and RX ports of the transceiver devices <NUM>-<NUM> in <FIG>). In UDP, which is a transport layer protocol, the UDP port number is a <NUM>-bit unsigned integer ranging from <NUM> to <NUM>, and a given process associates its input or output channel, via a socket, with a transport protocol and a port number, thereby enabling sending and receiving data via the network.

As illustrated in <FIG>, which will be further explained below, in the one-way information flow control device or system <NUM>, only the UDP datagram payload is relayed to the SNIC hardware (e.g., transceiver <NUM> and/or <NUM> of SNIC <NUM> shown in <FIG> and <FIG>) for further transmission as part of raw Ethernet frame(s) whose hardware destination address matches the MAC address of the transceiver device(s) of the RNIC (e.g., transceiver <NUM> and/or <NUM> shown in <FIG> and <FIG>). An example Ethernet frame format, which is illustrated in <FIG>, will be further explained below. Note that in <FIG> and <FIG>, the Ethernet frames sent by the SNIC primary transceiver <NUM> are rejected by the SNIC secondary transceiver device <NUM>, but are received by the RNIC primary transceiver device <NUM> as raw Ethernet frames destined for its own MAC address. Similarly, in <FIG>, the Ethernet frames sent by the SNIC secondary transceiver <NUM> are rejected by the SNIC primary transceiver device <NUM>, but are received by the RNIC secondary transceiver device <NUM> as raw Ethernet frames destined for its own MAC address. When the RNIC interfacing software <NUM> receives the Ethernet frames, only the frame payload is relayed forward, and the RNIC interfacing software <NUM> encapsulates the frame payload for transmission to the destination as UDP datagrams, as shown in <FIG>.

As shown in <FIG>, the Ethernet frame <NUM> is preceded by a preamble <NUM> field (<NUM> bytes) and SFD (start frame delimiter) <NUM> field (<NUM> byte). The Ethernet frame <NUM> includes Ethernet frame header <NUM>, Ethernet frame payload <NUM>, and cyclic redundancy check (CRC) <NUM>. The Ethernet frame header <NUM> includes the following fields: destination hardware address (MAC address) (<NUM> bytes); source hardware address (MAC address) (<NUM> bytes); and Ether type (<NUM> bytes). Ethertype values are defined in IEEE RFC7042 and RFC1701, and are located at byte [<NUM>] of the Ethernet frame shown in <FIG>. For example, EtherType value of 0x6559 indicates a "raw frame relay" Ethernet frame. The Ethernet frame payload <NUM> may be, e.g., <NUM>-<NUM> bytes, with some jumbo frames being as large as <NUM> bytes.

<FIG> shows a data-centric flow diagram illustrating various stages of data transfer and the associated data packet formatting as the data is transmitted from the information source network to the destination network via the send side and the receive side of the one-way information flow control device or system <NUM>. At stage <NUM>, as UDP travels through the information source network (e.g., information source <NUM> shown in <FIG>), the data packet may include, e.g., information-source-generated Ethernet frame header, information-source-generated IP packet header, information-source-generated UDP packet header, the payload, and information-source-generated Ethernet frame footer. At stage <NUM>, when the UDP datagram arrives on the receiving-side UDP socket, the data packet may include, e.g., information-source-generated UDP packet header, and the payload. At stage <NUM>, the payload is extracted in the send-side host platform (e.g., by the interfacing software <NUM> shown in <FIG> and <FIG>). At stage <NUM>, the payload is encapsulated in Ethernet frame for transfer from the send side of the one-way information flow control device or system <NUM> to the receive side, via the interface hardware, e.g., SNIC <NUM> and RNIC <NUM> shown in <FIG> and <FIG>. At stage <NUM>, the Ethernet frame is received on the receive side of the one-way information flow control device or system <NUM>, via interface hardware. At stage <NUM>, the payload is extracted in the receive-side host platform (e.g., by the interfacing software <NUM> shown in <FIG> and <FIG>) for processing. At stage <NUM>, the payload is encapsulated in UDP datagram for transfer to the destination. At stage <NUM>, the UDP datagram travels through the destination network.

In accordance with the hardware-enforced one-way information flow control device or system <NUM> of the present disclosure, IP and ARP protocols are not required and are not used for the communication between the SNIC <NUM> and the RNIC <NUM>. The RNIC does not require promiscuous mode configuration. Raw Ethernet frames as implement in accordance with the present disclosure, e.g., as illustrated in <FIG>, do not contain any IP information and are not routable. The RNIC <NUM>, which operates as a connectionless sniffer, receives and processes all Ethernet frames that are addressed specifically to the hardware address of the primary receiving transceiver device <NUM> (in the case of the embodiments shown in <FIG> and <FIG>) and to the hardware address of the secondary receiving transceiver device <NUM> (in the case of the embodiment shown in <FIG>), while other Ethernet frames are ignored by the RNIC <NUM>. Ethernet frames addressed to the receiving transceiver devices <NUM> and <NUM> are not routable, as they would be ignored by any other network device presenting a different hardware address. On the receiving side, Ethernet frames not presenting the expected Ethertype are dropped by RNIC interface software (e.g., interfacing software <NUM>).

In accordance with the hardware-enforced one-way information flow control device or system <NUM> of the present disclosure, the Ethernet frame's source hardware address (see, e.g., <FIG>) is irrelevant to the data transfer process, and the source hardware address field within the Ethernet frame may be reused for unrelated protocol information, or retained for purposes of security screening by RNIC interfacing software <NUM>. In addition, the RNIC <NUM> need not be configured to receive Ethernet frames in promiscuous mode operation in order to operate properly. However, in cases where promiscuous mode operation is implemented (e.g., due to deeply embedded device configurations which are not easily changeable), the RNIC interfacing software <NUM> may filter incoming ethernet frames based on Ethertype, source hardware address, and/or destination hardware address, all of which are accessible fields in the Ethernet frame header.

To recap, in accordance with the hardware-enforced one-way information flow control device or system <NUM> of the present disclosure, the interfacing software <NUM> and 3051access SNIC <NUM> and RNIC <NUM>, respectively, using raw socket programming techniques, in which raw sockets provide programming access to Ethernet frames where hardware (MAC) addresses and EtherType fields can be set and read. In addition, the split optical fiber connection is utilized to provide the hardware-enforced one-way information flow, along with the use of raw Ethernet frames, in which specific destination hardware addresses are specified, e.g., matched to the RNIC transceiver MAC address, or set to the explicit value of 0xFFFFFFFFFFFF (in which case it is broadcast to all hardware addresses).

As mentioned above, each optical transceiver (e.g., <NUM>-<NUM>) in the SNIC <NUM> and RNIC <NUM> presents a unique hardware address, also known as a Media Access Control (MAC) address, which is a unique identifier comprising <NUM> bytes and assigned to network interfaces for communications at the data link layer of a network segment. MAC address is used as a network address for most IEEE <NUM> network technologies, e.g., Ethernet and Wi-Fi. Logically, MAC addresses are used in the media access control protocol sublayer of the OSI reference model, for example. MAC addresses for the transceiver devices of SNIC <NUM> and RNIC <NUM> are visible to the operating systems of their respective host computer platforms.

In an example embodiment, e.g., as illustrated in <FIG> and <FIG>, one-way information flow control device or system of the present disclosure may be configured to transfer multiple concurrent lanes of independent information streams (e.g., multiple channels of streaming video) by inserting lane identifiers into UDP datagrams received in different inlet port numbers. In this example embodiment, the interface software for the RNIC associates each lane identifier with a different IP destination address and a port number. The number of configurable lanes is limited only by overall channel capacity of the one-way information flow control device or system (e.g., in the order of <NUM> Gbit/second) and bandwidth requirements of each individual lane. When lane identifiers are used, the one-way information flow control device or system conforms to a one-way information transfer pipeline that inherently supports a publisher/subscriber use case model. Only the send computing platform determines information flow into the invention, thereby publishing to an external platform. Only the receiving computer platform determines information flow from the invention, thereby subscribing to available information feeds.

<FIG> illustrates multiple independent streams of UDP packet flows using lane identifiers, which <FIG> provides a software-module-centric view of the UDP packet flows. In the example embodiment shown in <FIG>, the SNIC interfacing software <NUM> is augmented with UDP relay modules A (1102a, with associated port A), B (1102b, with associated port B) and C (1102c, with associated port C), to which multiple independent streams of UDP packets originating from UDP sources A (1101a), B (1101b) and C (1101c) are respectively relayed. UDP relay modules A (1102a), B (1102b) and C (1102c) each insert a lane identifier (ID) (e.g., lane A, lane B, lane C, etc.) based on the port assignment (e.g., port A, port B, port C, etc.) into the UDP packet in the respective UDP packet stream. The SNIC interfacing software <NUM> receives the multiple independent streams of UDP packets corresponding to lanes A, B and C via the UDP receiving socket <NUM>. The multiple independent streams of UDP packets corresponding to lanes A, B and C are processed by the payload processor 3021a and the frame constructor 3021b of the SNIC interfacing software <NUM> to generate corresponding multiple independent streams of Ethernet frames for lanes A, B and C, which Ethernet frames are transmitted using raw sending socket 3021c to the receiving side, i.e., RNIC <NUM>. On the receiving side, the multiple independent streams of Ethernet frames are received using raw socket 3051c, and the corresponding multiple independent streams of UDP packets corresponding to lanes A, B and C are generated from the received Ethernet frames by the payload processor 3051a and the UDP destination selector 3051b of the RNIC interfacing software <NUM>, using the lane-ID-to-destination mapping file <NUM>. The multiple independent streams of UDP packets are sent, e.g., using the UDP send socket <NUM>, to the respective destinations (e.g., destination 1103a with assigned port D for UDP stream A, destination 1103b with assigned port E for UDP stream B, and destination 1103c with assigned port F for UDP stream C.

<FIG> shows a flow diagram illustrating multiple independent streams of UDP packet flows using lane identifiers, which <FIG> provides a data-centric view of the UDP packet flows. The various data packets stages (e.g., <NUM> to <NUM>) shown in <FIG> substantially correspond to the various stages described above in connection with <FIG>, which provides a software-module-centric view of the UDP packet flows.

File transfers and other information flows may be achieved by direct resource access in proprietary interfacing software or by local protocol conversion to UDP datagrams at the inlet/outlet of the invention by separate software modules, including encrypted conduits and bilateral protocol proxies. <FIG> illustrates a software-module-centric view of a one-way direct file transfer mechanism using Ethernet frame relay. The target file to be transferred is read by the file data block reader of the SNIC interface, software, transferred through the one-way data transfer hardware using raw sockets to the receiving side, and a copy of the target file is written to the file transfer destination by the RNIC interface software module.

<FIG> illustrates a source-software-module-centric view of a one-way file transfer as a stream of UDP packets using lane identifiers. The target file to be transferred is read by the file-to-UDP module and transferred as UDP payload to the send-side of the one-way information control device. The SNIC interface software module transmits the payload transferred through the one-way data transfer hardware using raw sockets to the receiving side, and the RNIC interface software module transfers the file blocks as UDP payload to destinations as mapped to specific lane IDs associated with the payload streams. As shown in <FIG>, which illustrates a destination-software-module-centric view of the one-way file transfer as a stream of UDP packets using lane identifiers illustrated in <FIG>, the file blocks transmitted as UDP payload using the UDP send socket of the RNIC interface software is received by the UDP-to-file module, which in turn writes a copy of the target file to the file transfer destinations as mapped to specific lane IDs associated with the payload streams.

<FIG> illustrates an embodiment of one-way information flow control device or system which is coupled to the information source and destination using encrypted session proxy interfaces.

Data filters may be invoked by interfacing software if additional constraints on forward information flow are desirable. Multiple iterations of the one-way information flow control device, along with optional data filters, may be connected in series, e.g., as illustrated in <FIG>, to create an assured one-way pipeline information flow architecture. The one-way pipeline information flow architecture shown in <FIG> may be modified, e.g., wrapped into a loop, thereby creating a "transactional closed travers" arrangement, which has beneficial applications in the field of transaction processing, for example.

<FIG> is a flow diagram illustrating an example implementation of the non-routable "protocol break" (also referred to as "protocol transition") is achieved. Only raw Ethernet frames are sent to and from the SNIC and RNIC transceiver devices. The Hardware address fields in the Ethernet frames are matched to the RNIC device, which is a core feature of all embodiments described and illustrated in the present disclosure. Configured this way, there is no IP source or destination information in data that passes between the SNIC and RNIC host computers. In other words, the core Diode protocol is a "raw frame relay" that is not routable.

<FIG> illustrates an example embodiment of host computer platform hardware, e.g., inlet host computer platform <NUM> and outlet host computer platform <NUM>, with respective NICs (SNIC for inlet host computer platform <NUM>, and RNIC for outlet host computer platform <NUM>).

<FIG> illustrates a high-level overview of a one-way information flow control system or a data communication system having a one-way information flow control device <NUM> according to the present disclosure. One or more information source(s) <NUM> is connected on a transmission side of the information flow control device <NUM>, while one or more information monitor(s) <NUM> is connected on a receiving side of the information flow control device <NUM>. The information sources <NUM> may be part of or originate from a secure facility or critical infrastructure <NUM>, such as a nuclear power plant. The information sources may include sensors, monitoring devices, controllers, computers, machines, and/or the like which obtain and/or generate data <NUM> about the facility. In the context of a nuclear power plant, the information sources may include components of reactor vessels, pumps, and turbines and provide sensitive and/or non-sensitive data. The information monitors <NUM> may be part of another facility or infrastructure <NUM> that monitors data provided by the information sources (e.g., operating parameters of an information source machine or facility). In some instances, an information monitor may include a computing device, such as a desktop computer, laptop, tablet, mobile device, or the like, through which a user can view detailed information from the information sources. The information monitor may include the user acting on the data from the information sources. In some instances, the information monitor may be configured to analyze the incoming data <NUM> for alarm conditions and/or generate an output based on the data. As shown in <FIG>, the one-way information flow control device has at least two transmit modules <NUM>, <NUM> and at least one receive module <NUM>. The transmit and receive modules may be provided in a single enclosure, or alternatively, they are in separate enclosures (as depicted by the dashed line). In some embodiments, the enclosures are tamper-resistant in order to prevent or reduce the likelihood of unauthorized reconfiguration of the one-way information flow control device.

The configurations and techniques described herein are exemplary, and should not be construed as implying any particular limitation on the present disclosure. It should be understood that various alternatives, combinations and modifications could be devised by those skilled in the art. For example, steps associated with the processes described herein can be performed in any order, unless otherwise specified or dictated by the steps themselves. The present disclosure is intended to embrace all such alternatives, modifications and variances that fall within the scope of the appended claims.

Claim 1:
A one-way information flow control device (<NUM>, 100a, 100b, 100c, 100d), between an isolated Industrial Control System, ICS, network (<NUM>) and a public access network (<NUM>), comprising:
a first network interface card (<NUM>) on a transmission side, the first network interface card (<NUM>) including a first transceiver (<NUM>) and a second transceiver (<NUM>), each of the first and second transceivers having a transmit port (TX) and a receive port (RX);
a second network interface card (<NUM>) on a receiving side, the second network interface card (<NUM>) including at least one receive port (RX);
characterized in that the one-way information flow control device (<NUM>, 100a, 100b, 100c, 100d) further comprises:
a first data connection segment (<NUM>) connecting the first transceiver transmit port (<NUM>, TX) of the first network interface card (<NUM>) to the second transceiver receive port (<NUM>, RX) of the first network interface card (<NUM>);
a second data connection segment (<NUM>) connecting the second transceiver transmit port (<NUM>, TX) of the first network interface card (<NUM>) to the first transceiver receive port (<NUM>, RX) of the first network interface card (<NUM>); and
a third data connection segment (<NUM>) connecting the first transceiver transmit port (<NUM>, TX) of the first network interface card (<NUM>) to the receive port (RX) of the second network interface card (<NUM>);
whereby interconnection of the first and second transceivers (<NUM>, <NUM>) provides for sensing a datalink connection, while connection of the first transceiver transmit port (<NUM>, TX) of the first network interface card (<NUM>) and the receive port (RX) of the second network interface card (<NUM>) enables one-way data transfer.