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.
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.
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.
Oh, and if you controlled the software stack on the two rpi's there's a good chance there's a side channel somewhere
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.
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.
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.
> which shouldn't be necessary unless you're pushing the limits of its rise/fall times
Right, I should have clarified this. To make them go fast, you can often use more power (to a point), and that can shorten the LED lifespan. (To be fair, there are techniques to give you a bit faster speed without making them too bright, like pulse-shaping, but it didn't appear anything that fancy was going on there.)
And, unfortunately, "fast" for the optoisolator isn't very, in any case. The cut-off frequency for the first datasheet I found corresponding to that app note was 80 KHz.
> I think the galvanic isolation is mostly a feelgood here,
And...
I don't get this.
If it does nothing useful, why bother?
IMO, the primary good use for an optoisolator these days is either for something analog-ish like the feedback for a switch mode power supply, or for when you're breadboarding something with really high voltages and don't want to bother with SMT devices.
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.
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.
Real data diode and cross domain solutions are super expensive for this reason.
> 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.
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.
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"
It does the job, but the enclosures are plastic, they are tough, but I would preferred some machined aluminium.
It may be possible to increase the bandwidth by increasing the sample rate on both ends, but this quickly leaves the realm of consumer audio equipment (and consumer pricing). At some point you'd exceed the reasonable frequency responses for each device, as well as the medium. I imagine that air attenuates ultrasonic frequencies more than lower ones, but that's just a guess.
That said, I believe optical isolation is typical for these "data diode" applications, even between two computers in the same rack. I don't think it provides any security benefit, but it's cheap and customers expect it; so there's no commercial incentive to do anything else.
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.
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.
Gut feeling tells me there is a way, if you use way more power than normal for this :). Much like with making speakers receive sound (you need to amplify the received signal afterwards) and making microphones produce it.
But it doesn't really matter whether or not you can reverse the analog signal flow, if the digital side treats the I/O pins as unidirectional.
The threat model where you use a data diode presumes an adversary might totally compromise the sending side - the guarantee you're trying to add is that whatever malware they push down the line has no ability to exfiltrate data regardless of how compromised it is.
No. "An air-gapped computer or network is one that has no network interfaces, either wired or wireless, connected to outside networks" https://en.wikipedia.org/wiki/Air_gap_(networking)#Use_in_cl...
there are a lot of such extremely hypothetical attacks no one should take seriously. you might as well worry about sensitive data being exfiltrated from your unshielded optical nerve,
So there's still an attack surface, but it's a lot smaller. Any side channel exploit would need to work (at least in some initial form) without changes to the software on the isolated side, since you otherwise can't bootstrap your way to installing it.