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