I wrote this to share my experience building a secure one-way data transfer solution for air-gapped systems. Happy to answer technical questions about why we chose this architecture and the challenges we faced, lots of ways to solve this problem, but this is my way.
This is pretty neat, but is what you pictured the final product? It doesn't strike me as sufficiently robust for deployment. More like an engineering concept...
The "RS-232" part is important here, since directly connecting the UART pins for the two MCUs without the RS-232 level shifters may trivially permit bidirectional dataflow, for example by reconfiguring the pins to GPIO and bit-banging a UART in the reverse direction, as already noted below. That wouldn't be directly exploitable (since you'd need to somehow bootstrap that reconfiguration in), but it would widen the attack surface.
If the cable wires control signals like DTR and RTS, then you'd need to cut those too. The goal in any case is one wire (plus ground) out of the transmitter and one wire into the receiver, with something in between that enforces data flow in only one direction. An optoisolator can do that, but a buffer without galvanic isolation (like the RS-232 level shifters) can do that too.
There's only a couple of cases where this can go wrong. Either the contents of what is being sent out could be wrong, or the hardware itself could be tampered with to extract extra information on another optical or radio channel. Both of these require extensive software tampering. In the simple case where you trust the software on both sides, and the hardware, this can be practically as good as it gets (with the requirement that the inside be monitored automatically somehow).
I'm assuming you don't have any audit requirements for this application. The stupid pricing for hardware often isn't in the hardware, it's in the compliance.
Why not use optical ethernet as ‘real’ cross domain solutions do? Probably cheaper if you don’t mind eBay, and gives you an easy upgrade path to 10Gbps or more in future.
Two port NIC on the low side. Port 2 has its TX side connected to Port 1’s RX, just so the port will see a carrier and show link up. Port 1 TX goes to the high side machine’s RX, with TX left open.
From here, you have a whole ton of protocol options.
For things like syslog, you can just use a static ARP entry on the low side to forward events to the high side’s IP address via UDP.
For reliable transport, there are lots of options for reliable multicast now using erasure coding etc that don’t require a reverse channel.
Or you could get 10Mbps Ethernet hardware and cut the receive line.
I don't know the specifics, including what particular Ethernet tech it was that allowed it to work, just heard someone talking about it some decades ago.
Is raspberry pi a good choice for this? How auditable is the SOC on this thing? As I understand it, there is an administrative core that you can't reprogram and that has DMA to the user core and provide DRM decoding. It could be doing anything.
> An opto coupler, also known as an opto isolator, allows an electrical signal to pass from one device to another using light, preventing direct electrical connection. *This ensures data flows in a single direction, maintaining the integrity of the air gap.*
I would like to know how they come to such a conclusion as this is either a misunderstanding or an AI solution. The opto isolator does not maintain the air gap. It only provides galvanic isolation which is likely unnecessary in this situation.
Galvanic isolation is useful in situations where you want to isolate circuits from electrical potential issues (ground loops and so on) or isolation from noise and faults.
I feel like it's easier to just have Ethernet and a strict HW firewall with the admin interfaces totally disabled (have to full reset to get back in).
You can either just block packets in one direction, or you can add a small amount of risk and allow UDP and TCP with zero payload in one direction. That would allow you to reliably stream in one direction and request from either direction, albeit with a slightly exploitable channel (timing, reliability or the space of values allowed in the protocol).
You already have to trust the RPI hardware to not enable WiFi on either side, so why not trust a router?
> I feel like it's easier to just have Ethernet and a strict HW firewall with the admin interfaces totally disabled (have to full reset to get back in).
Easier? Maybe, for certain values of easy, but as others have noted it's not hard to build a data diode setup using fiber ethernet and from there you just have to hardcode some ARP data and maybe a route entry to allow UDP to flow.
The thing is that with your solution as long as the firewall works properly data shouldn't be able to leak in the wrong direction. With a proper data diode, as long as physics continues to function more or less how we understand it you can prove that data can not leak in the wrong direction. That's a huge difference, especially when it comes to explaining what you're doing to non-technical higher ups, auditors, lawyers, etc.
If galvanic isolation is necessary, there are "digital isolators" (that's a good search term if you are interested) that are much faster than optocouplers and that don't suffer from the same sort of degradation (over a few years, the LED gets dimmer and dimmer).
But there's probably no galvanic isolation going on here anyway, so a wire, or at most a simple logic buffer, would probably suffice.
If I'm connecting two things from different power domains, I like to use gates (or level shifters, if necessary) that are designed for the task. These will keep stray currents from causing electromigration problems when one is powered on and the other is powered off, and some of these are very fast, over 100 MB/s.
> over a few years, the LED gets dimmer and dimmer
That shouldn't happen unless the LED is driven near the top of its current rating, which shouldn't be necessary unless you're pushing the limits of its rise/fall times (in which case a different part would be advisable as you say).
A random app note shows 95% of initial current transfer ratio after 25 years at If = 5 mA, and depending on the necessary bit rate we could probably design for at least 2x initial margin on that CTR. Such a design would last effectively forever.
I think the galvanic isolation is mostly a feelgood here, allowing people to say it's "air-gapped" even though that's not directly relevant (since Wi-Fi is also "air-gapped"). A simple gate or level shifter can also enforce unidirectional data flow as you say.
The main function of this gear is preventing the ingress of control to a sensitive network, whilst also allowing a controlled outflow of data for monitoring. I think the design choices made were all quite reasonable. Given that it passed an audit, it seems reasonably trustworthy.
The stock raspberry pi doesn't have wireless ports to serve as potential side channels. The use of an opto-isolator means that data is constrained by physics to only flow in the desired direction, no matter what happens in either Raspberry Pi.
It should be possible to replicate this for less that $200 in hardware.
Everyone commenting about the strict definition is a very smart boy. Good job and gold stars all around for the productive conversation! You're solving the real problems of our times here.
There are reasons that the US Government is super serious about certifying data diodes and cross domain solutions because you need to be absolutely sure what you are doing doesn’t accidentally leak data where it doesn’t need to go.
Real data diode and cross domain solutions are super expensive for this reason.
Once I have a reliable network diode in place, is there an open source software stack to help me move the various kinds of OS updates, repos, and mirrors that I need? I can do this kind of stuff, but I know I’m reinventing the wheel.
26 comments
[ 3.0 ms ] story [ 40.6 ms ] threadIf the cable wires control signals like DTR and RTS, then you'd need to cut those too. The goal in any case is one wire (plus ground) out of the transmitter and one wire into the receiver, with something in between that enforces data flow in only one direction. An optoisolator can do that, but a buffer without galvanic isolation (like the RS-232 level shifters) can do that too.
Two port NIC on the low side. Port 2 has its TX side connected to Port 1’s RX, just so the port will see a carrier and show link up. Port 1 TX goes to the high side machine’s RX, with TX left open.
From here, you have a whole ton of protocol options.
For things like syslog, you can just use a static ARP entry on the low side to forward events to the high side’s IP address via UDP.
For reliable transport, there are lots of options for reliable multicast now using erasure coding etc that don’t require a reverse channel.
I don't know the specifics, including what particular Ethernet tech it was that allowed it to work, just heard someone talking about it some decades ago.
I would like to know how they come to such a conclusion as this is either a misunderstanding or an AI solution. The opto isolator does not maintain the air gap. It only provides galvanic isolation which is likely unnecessary in this situation.
Galvanic isolation is useful in situations where you want to isolate circuits from electrical potential issues (ground loops and so on) or isolation from noise and faults.
You can either just block packets in one direction, or you can add a small amount of risk and allow UDP and TCP with zero payload in one direction. That would allow you to reliably stream in one direction and request from either direction, albeit with a slightly exploitable channel (timing, reliability or the space of values allowed in the protocol).
You already have to trust the RPI hardware to not enable WiFi on either side, so why not trust a router?
Easier? Maybe, for certain values of easy, but as others have noted it's not hard to build a data diode setup using fiber ethernet and from there you just have to hardcode some ARP data and maybe a route entry to allow UDP to flow.
The thing is that with your solution as long as the firewall works properly data shouldn't be able to leak in the wrong direction. With a proper data diode, as long as physics continues to function more or less how we understand it you can prove that data can not leak in the wrong direction. That's a huge difference, especially when it comes to explaining what you're doing to non-technical higher ups, auditors, lawyers, etc.
But there's probably no galvanic isolation going on here anyway, so a wire, or at most a simple logic buffer, would probably suffice.
If I'm connecting two things from different power domains, I like to use gates (or level shifters, if necessary) that are designed for the task. These will keep stray currents from causing electromigration problems when one is powered on and the other is powered off, and some of these are very fast, over 100 MB/s.
That shouldn't happen unless the LED is driven near the top of its current rating, which shouldn't be necessary unless you're pushing the limits of its rise/fall times (in which case a different part would be advisable as you say).
A random app note shows 95% of initial current transfer ratio after 25 years at If = 5 mA, and depending on the necessary bit rate we could probably design for at least 2x initial margin on that CTR. Such a design would last effectively forever.
https://www.we-online.com/catalog/media/o303314v410%20ANO006...
I think the galvanic isolation is mostly a feelgood here, allowing people to say it's "air-gapped" even though that's not directly relevant (since Wi-Fi is also "air-gapped"). A simple gate or level shifter can also enforce unidirectional data flow as you say.
The stock raspberry pi doesn't have wireless ports to serve as potential side channels. The use of an opto-isolator means that data is constrained by physics to only flow in the desired direction, no matter what happens in either Raspberry Pi.
It should be possible to replicate this for less that $200 in hardware.
Real data diode and cross domain solutions are super expensive for this reason.