Creating a bespoke data diode for air‑gapped networks (opens in new tab)

That's kind of brilliant. I had no idea that kind of thing would actually work. I always assumed that bidirectional connections were needed to allow ETH frames to function, electrically. I further assumed this applied to optical networking too.

My understanding is that there has to be a heartbeat sent in both directions for fiber Ethernet to work. There are work arounds, but then you're back up into the commercial product price range.

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.

It's easier than that. You don't need two NICs to get a carrier, just use a fiber coupler. They are super cheap (< $30)

Whether you want to define it as a true air gap or not, this is effectively how most "air gapped" clouds work, with diodes.

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).

Last I checked, light does indeed cross gaps of air, so "air gapped" is at least more appropriate than your comment.

yes, but if your adversary is capable of exploiting a one-way diode to RCE, you might as well just give up.

I don’t see what diving into pointless semantics adds to the discussion here.

Unless the mossad is after you one way light based coms may as well be

Yep that would work, there's a whole heap of ways to solve the problem, have heard of people using fiber connections and curring one side. But I just wanted something simple for me, I know Linux and Raspberry pi's so decided to go down this route, having a pi on each side gives me the option to run scripts and tweak as required.

How confident are you that a compromised receiving machine able to send arbitrary voltages on 8 of the 9 pins wouldn't be able to trigger some unexpected behavior on the airgapped machine?

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.

Here it might fail. If you were sufficiently motivated and controlled the software stacks on the rpi's you may be able to get data to flow in the other direction. LEDs have their voltage modulated by light. And it's possible that is the voltage on the transistor if properly modulated it may able to emit light. It's a lot of ifs and requires the adc of the rpi to be sensitive enough (and one of the pinmux options). But it's why certifying is important.

Oh, and if you controlled the software stack on the two rpi's there's a good chance there's a side channel somewhere

Also very low sales volume.

I think they only care about preventing data flow in one direction while still allowing it in the other. This isn't strictly an air gap, but it fits their use of the term "data diode". The fact that the unidirectional flow of information is achieved through galvanic isolation is probably just a side effect. In the ideal case, no information can flow from the photosensitive element to the LED. A determined attacker could probably exploit lots of side channels here, though.

A single optoisolator will certainly enforce one-way airgap. Two optoisolators are required for tx and rx.

I don't understand your point. Isn't the galvanic isolation implemented in the optoisolator by an air gap between the light transmitter and receiver? Maybe I don't know the definition of air gap?

> 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.

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.

> 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.

Two separate networks, completely isolated, the only bit connecting the two is the opto coupler.

Was all audited by their internal sec department.

They are happy, it was an interesting problem, they need a bunch of seriously old kit well away from their network, so put it on its own isolated network, but then they realised they also wanted to get some info out of the old kit.

Therefore this project was launched.

Luckily it's not an industry like defense.

Both pi's are locked down, handed over to the right folks and I am locked out.

Can you share how the scripts work? That seems to be the most interesting part, but is omitted from the article. The only technical details are UART + an opto-coupler.

> Both devices run custom scripts designed to handle data transmission reliably rather than quickly. This approach limits throughput, but reliability is paramount for critical monitoring, where losing data is unacceptable. The scripts are finely tuned to ensure that every log entry is transmitted securely without risk of cross-contamination between networks.

Very curious what the hinted at issues were with using regular unidirectional serial before introducing the pair of Pis.

The final product is in a pi enclosure that is stackable, the two pi's live inside with the opto coupler installed inside.

It does the job, but the enclosures are plastic, they are tough, but I would preferred some machined aluminium.

I think the benefit of a discrete optocoupler is in keeping the communication point-to-point, so no other device (malicious or otherwise) can "listen in". A low-power light signal won't penetrate a solid enclosure; it's much harder to prevent mechanical vibrations from leaking information beyond the coupler - you'd need to keep the speaker and microphone on some kind of suspension (springs and shock absorbers) acting as a low-pass filter.

That has to be abysmal bandwidth, right? How much data can you practically transfer that way?

Ohhh that's a cool idea. I love any project that uses audio.

This is a real vector - I had this happen in undergrad EE where my serial line to my microcontroller had a bunch of legible garbage on it. Turns out my MacBook charger was also using serial to talk to the laptop, with enough power to radiate to the otherwise isolated microcontroller serial line.