[nelop]

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.

[oconnore]

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.

[nelop]

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.

[tonyarkles]

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

[nelop]

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.

[StevenThompson]

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.

[nancyminusone]

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"

[nelop]

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.

[tonyarkles]

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