This is entirely hypothetical. It is not advice. It is not a recommendation. It is a thought experiment that assumes a slightly paranoid mindset and a background in locking down systems that most people are happy to just plug into the internet.

Pretty confident, if the recieving machine is compromised, it is only connected to the opto coupler, that ensures only one way traffic, on one pin.

Somehow you would have to get a receive pin to transmit, and then get through the opto coupler and then it just hits a pin that's designed to only send data.

Sorry, I didn't mean for your project, but for using a RS232 null modem like OP suggested

Pins on modern hardware like that are all bidirectional you set the direction in software normally.

Ohhh that's a good point, you can set the Rx pin to Tx, then it still has to get through the opto isolator, and then it's talking to a port that's set to Tx.

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

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.

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.

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.

I just let them use my ubuntu machine, they 50% of what they do is through a browser, so have setup their own profile, and the other 50% is gaming.

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.

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.

Yep they are pretty simple, on one end you have a python script that listens to syslog messages, when get gets an interesting one it converts into a binary string and sends out over GPOI14.

This goes through an opto coupler

On the other end there a python script listening on GPIO16, it takes a string of binary data, decodes, checks it's valid, then creates a tagged syslog message. Syslog is configured to forward everything onto a central location for folks to monitor.

Hope that makes sense.

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

The problems was all my fault :-) I was trying to use a port that was not designed for serial data. When data was sent across it was getting mashed. I think it's because both ports were not uart, therefore when the binary data was sent if they were not perfectly in sync it would get mashed, I might have been able to solve it by sending a clock as well. But the easier option was to just change everything to the uart ports and it magically worked.

It was probably due to the lack of flow control. Serial doesn't work well when it's one-way. I did something similar to send logs waaaay back in the day, and it would constantly flip bits or send characters out of sequence, etc. I had to transmit very slowly to get it to work stably without any flow control. I want to say that I limited it to 9600 kbps before it started to become reliable.

For that matter, why the optocoupler at all? You only need it if the systems are at different electrical potentials, and even then they are galvanically isolated on the Pis by the magnetics in the Ethernet.

But I guess it's not the same as being asked "where's the air gap" pointing at the optocoupler, and saying "there it is"

There are lots of ways to solve this problem.

In the past I have worked in defence, for highly sensitive stuff they wouldn't even allow a common ground between two networks.

That's why I chose an option iolsator, it ensures the two devices are electrically isolated.

It's overkill for this application, but I wanted to set something up right, and if I ever have another project like this that needs to be more secure, it's ready to go.

> In the past I have worked in defence, for highly sensitive stuff they wouldn't even allow a common ground between two networks.

I actually agree very much with this. If you're looking for strong assurance that there is no possible back-channel, devices like optocouplers help significantly. It's not hard for me to think of a way to surreptitiously send data backwards through a common ground, or normal silicon diode, or a magnetic coupler like an Ethernet transformer, but optoisolators make it significantly more challenging.