Could've used a speaker and microphone with an appropriate noise-resistant digital encoding.
That has to be abysmal bandwidth, right? How much data can you practically transfer that way?
Creating a bespoke data diode for air‑gapped networks
31–40 of 86 posts
Re: Creating a bespoke data diode for air‑gapped networks
#32Could'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…
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).
Re: Creating a bespoke data diode for air‑gapped networks
#33A "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.
I don’t see what diving into pointless semantics adds to the discussion here.
Re: Creating a bespoke data diode for air‑gapped networks
#34I'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.
Re: Creating a bespoke data diode for air‑gapped networks
#35Those wires are certainly long enough to be antennas.
Re: Creating a bespoke data diode for air‑gapped networks
#36Just use DNS.
Re: Creating a bespoke data diode for air‑gapped networks
#37Why 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.
Re: Creating a bespoke data diode for air‑gapped networks
#38Is 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.
Re: Creating a bespoke data diode for air‑gapped networks
#39Earlier quoted context omitted.
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…
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.
Re: Creating a bespoke data diode for air‑gapped networks
#40I'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