Why not use optical ethernet as ‘real’ cross domain solutions do? Probably cheaper if you don’t mind eBay, and gives you an easy upgrade path to 10Gbps or more in future.
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.
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.
For 100BaseFX and 1000BaseSX at least, there’s no auto negotiation for link speed etc. As long as it sees a carrier from what it thinks is the other end of the link, it’s happy.
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.
You can, but a 1x2 multimode splitter is not something people generally have on hand, whereas 1000BaseSX cards (or media converters) and ordinary patch cables are easy to find.
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).
both of these require the isolated machine to be heavily compromised to begin with.
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,
Eavesdropping on stray RF signals is not so theoretical though. It's been done by NSA and no doubt others. We also need to worry about hardware supply chains including random compromised stuff that "accidentally" leaks or exposes backdoors.
If I gave away a PC with perfect RF isolation and a rock solid supply chain it wouldn’t improve most user’s overall security because their operational security is so poor. There is no need for any organization to snoop your RF when you’re leaking everything they care about in your metadata.
In many industrial applications, the concern is mostly control of the isolated side, like because that could physically destroy stuff. Exfiltration is a smaller or nonexistent concern, since you're already sending most data out deliberately.
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.
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.
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.
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?
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.
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.
I'm assuming you don't have any audit requirements for this application. The stupid pricing for hardware often isn't in the hardware, it's in the compliance.
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
I reckon it is also possible to set up a second channel covertly at a higher frequency. It may also have surprising flaws. People have read network packets from router indicator LEDs lol.
The main function of this gear is preventing the ingress of control to a sensitive network, whilst also allowing a controlled outflow of data for monitoring. I think the design choices made were all quite reasonable. Given that it passed an audit, it seems reasonably trustworthy.
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.
> An opto coupler, also known as an opto isolator, allows an electrical signal to pass from one device to another using light, preventing direct electrical connection. *This ensures data flows in a single direction, maintaining the integrity of the air gap.*
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.
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.
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?
Once I have a reliable network diode in place, is there an open source software stack to help me move the various kinds of OS updates, repos, and mirrors that I need? I can do this kind of stuff, but I know I’m reinventing the wheel.
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).
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?
> 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.
There are reasons that the US Government is super serious about certifying data diodes and cross domain solutions because you need to be absolutely sure what you are doing doesn’t accidentally leak data where it doesn’t need to go.
Real data diode and cross domain solutions are super expensive for this reason.
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.
Everyone commenting about the strict definition is a very smart boy. Good job and gold stars all around for the productive conversation! You're solving the real problems of our times here.
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.
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"
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.
This is pretty neat, but is what you pictured the final product? It doesn't strike me as sufficiently robust for deployment. More like an engineering concept...
If galvanic isolation is necessary, there are "digital isolators" (that's a good search term if you are interested) that are much faster than optocouplers and that don't suffer from the same sort of degradation (over a few years, the LED gets dimmer and dimmer).
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.
> 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.
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.
I think those optoisolators are indeed sold mostly for switching power supplies. That's probably why someone cared enough about aging to write an app note, since the ambient temperature is high there and the exact CTR matters more when it's in that analog feedback loop. I've also seen them for digital inputs in industrial control systems, where speeds are slow and the wires might be coming from far away on a noisy ground.
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.
Is raspberry pi a good choice for this? How auditable is the SOC on this thing? As I understand it, there is an administrative core that you can't reprogram and that has DMA to the user core and provide DRM decoding. It could be doing anything.
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.
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.
All speakers can act as microphones. But due to physics you'd have a much harder time turning a photodiode into a light emitting one (the physics means you only can get IR out and the LED can't receive anything that way).
> the physics means you only can get IR out and the LED can't receive anything that way
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.
If the digital side could be trusted we'd just set it to send only mode and be sure it'll behave - in reality we don't trust it.
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.
Shannon-Hartley says the theoretical maximum data rate for a channel with AWGN is proportional to bandwidth and the log of signal-to-noise ratio. For an off-the-shelf microphone/speaker pair, I think 16 kHz and 80 dB are probably decent guesses. That would give a theoretical maximum data rate of about 425 kb/s. The practical limit is probably much lower.
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.
Why not use optical ethernet as ‘real’ cross domain solutions do? Probably cheaper if you don’t mind eBay, and gives you an easy upgrade path to 10Gbps or more in future.
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.
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.
For 100BaseFX and 1000BaseSX at least, there’s no auto negotiation for link speed etc. As long as it sees a carrier from what it thinks is the other end of the link, it’s happy.
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.
Using a two port NIC on the transmit side as I described addresses this. This is exactly how commercial CDS vendors like BAE Systems do it.
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)
You can, but a 1x2 multimode splitter is not something people generally have on hand, whereas 1000BaseSX cards (or media converters) and ordinary patch cables are easy to find.
A "diode" is not an air gap. If there is any flow in either direction, you don't have an air gap. This isn't hard to understand.
Whether you want to define it as a true air gap or not, this is effectively how most "air gapped" clouds work, with diodes.
Last I checked, light does indeed cross gaps of air, so "air gapped" is at least more appropriate than your comment.
By that logic, an open wifi router would be considered air gapped, n’est pas?
I don’t see what diving into pointless semantics adds to the discussion here.
Because a company advertising security solutions who misunderstands basic terminology is highly suspect.
Good thing it's only important semantics that are being dived into then
Unless the mossad is after you one way light based coms may as well be
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).
yes, but if your adversary is capable of exploiting a one-way diode to RCE, you might as well just give up.
Prepare to give up I'd say[1][2].
[1]: https://arxiv.org/abs/1503.07919
[2]: https://arxiv.org/abs/2012.06884
both of these require the isolated machine to be heavily compromised to begin with.
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,
Eavesdropping on stray RF signals is not so theoretical though. It's been done by NSA and no doubt others. We also need to worry about hardware supply chains including random compromised stuff that "accidentally" leaks or exposes backdoors.
If I gave away a PC with perfect RF isolation and a rock solid supply chain it wouldn’t improve most user’s overall security because their operational security is so poor. There is no need for any organization to snoop your RF when you’re leaking everything they care about in your metadata.
In many industrial applications, the concern is mostly control of the isolated side, like because that could physically destroy stuff. Exfiltration is a smaller or nonexistent concern, since you're already sending most data out deliberately.
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.
Yes, this is about as secure as any network connection can be made.
Unless you needed Ethernet, you could have done the same thing with a null modem RS-232 cable with the TX pin cut on one end.
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.
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.
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?
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.
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.
Sorry, I didn't mean for your project, but for using a RS232 null modem like OP suggested
What voltages would these be? If the receiver and transmitter are both the same as in the article then I don't see how this is an issue.
I'm assuming you don't have any audit requirements for this application. The stupid pricing for hardware often isn't in the hardware, it's in the compliance.
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
I reckon it is also possible to set up a second channel covertly at a higher frequency. It may also have surprising flaws. People have read network packets from router indicator LEDs lol.
Also very low sales volume.
The main function of this gear is preventing the ingress of control to a sensitive network, whilst also allowing a controlled outflow of data for monitoring. I think the design choices made were all quite reasonable. Given that it passed an audit, it seems reasonably trustworthy.
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.
> An opto coupler, also known as an opto isolator, allows an electrical signal to pass from one device to another using light, preventing direct electrical connection. *This ensures data flows in a single direction, maintaining the integrity of the air gap.*
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.
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.
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?
The point is you don't need the opto isolator at all.
That's a separate point. Are you agreeing that if an air gap was needed an optoisolator would be suitable?
A single optoisolator will certainly enforce one-way airgap. Two optoisolators are required for tx and rx.
Once I have a reliable network diode in place, is there an open source software stack to help me move the various kinds of OS updates, repos, and mirrors that I need? I can do this kind of stuff, but I know I’m reinventing the wheel.
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).
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?
> 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.
There are reasons that the US Government is super serious about certifying data diodes and cross domain solutions because you need to be absolutely sure what you are doing doesn’t accidentally leak data where it doesn’t need to go.
Real data diode and cross domain solutions are super expensive for this reason.
I don't see how this is airgapped. You literally connect a full Pi to the RXing computer. What audit has RX Pi device gone through?
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.
Everyone commenting about the strict definition is a very smart boy. Good job and gold stars all around for the productive conversation! You're solving the real problems of our times here.
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.
This is pretty neat, but is what you pictured the final product? It doesn't strike me as sufficiently robust for deployment. More like an engineering concept...
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.
Commercial data diodes tend to use fiber optics and disable the transmitter on one end and the receiver on the other end.
If galvanic isolation is necessary, there are "digital isolators" (that's a good search term if you are interested) that are much faster than optocouplers and that don't suffer from the same sort of degradation (over a few years, the LED gets dimmer and dimmer).
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.
> 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.
Upvoted for:
> 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.
I think those optoisolators are indeed sold mostly for switching power supplies. That's probably why someone cared enough about aging to write an app note, since the ambient temperature is high there and the exact CTR matters more when it's in that analog feedback loop. I've also seen them for digital inputs in industrial control systems, where speeds are slow and the wires might be coming from far away on a noisy ground.
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.
Is raspberry pi a good choice for this? How auditable is the SOC on this thing? As I understand it, there is an administrative core that you can't reprogram and that has DMA to the user core and provide DRM decoding. It could be doing anything.
Those wires are certainly long enough to be antennas.
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.
Could've used a speaker and microphone with an appropriate noise-resistant digital encoding.
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.
All speakers can act as microphones. But due to physics you'd have a much harder time turning a photodiode into a light emitting one (the physics means you only can get IR out and the LED can't receive anything that way).
> the physics means you only can get IR out and the LED can't receive anything that way
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.
If the digital side could be trusted we'd just set it to send only mode and be sure it'll behave - in reality we don't trust it.
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.
That has to be abysmal bandwidth, right? How much data can you practically transfer that way?
Shannon-Hartley says the theoretical maximum data rate for a channel with AWGN is proportional to bandwidth and the log of signal-to-noise ratio. For an off-the-shelf microphone/speaker pair, I think 16 kHz and 80 dB are probably decent guesses. That would give a theoretical maximum data rate of about 425 kb/s. The practical limit is probably much lower.
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.
Ohhh that's a cool idea. I love any project that uses audio.
Just use DNS.