_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
URI Visit Hacker News on the Web
COMMENT PAGE FOR:
URI Creating a bespoke data diode for airâgapped networks
firesteelrain wrote 9 hours 2 min ago:
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.
estimator7292 wrote 11 hours 0 min ago:
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.
mikewarot wrote 12 hours 27 min ago:
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.
UltraSane wrote 13 hours 30 min ago:
Commercial data diodes tend to use fiber optics and disable the
transmitter on one end and the receiver on the other end.
zephen wrote 13 hours 32 min ago:
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.
tripletao wrote 8 hours 43 min ago:
> 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. [1] 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.
URI [1]: https://www.we-online.com/catalog/media/o303314v410%20ANO006...
zephen wrote 6 hours 53 min ago:
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.
tripletao wrote 5 hours 29 min ago:
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.
avidiax wrote 14 hours 15 min ago:
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?
wolrah wrote 6 hours 45 min ago:
> 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.
MisterTea wrote 14 hours 53 min ago:
> 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.
mhb wrote 12 hours 41 min ago:
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?
MisterTea wrote 10 hours 17 min ago:
The point is you don't need the opto isolator at all.
mhb wrote 9 hours 53 min ago:
That's a separate point. Are you agreeing that if an air gap was
needed an optoisolator would be suitable?
idiotsecant wrote 14 hours 2 min ago:
A single optoisolator will certainly enforce one-way airgap. Two
optoisolators are required for tx and rx.
bmgxyz wrote 14 hours 30 min ago:
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.
neuroelectron wrote 15 hours 21 min ago:
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.
bigfatkitten wrote 15 hours 29 min ago:
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.
pseudohadamard wrote 6 hours 59 min ago:
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.
PaulCarrack wrote 8 hours 39 min 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)
bigfatkitten wrote 7 hours 5 min 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.
mikewarot wrote 12 hours 34 min ago:
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.
bigfatkitten wrote 12 hours 10 min ago:
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.
pragma_x wrote 14 hours 13 min ago:
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.
bigfatkitten wrote 11 hours 49 min ago:
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.
EAtmULFO wrote 15 hours 30 min ago:
Just use DNS.
buckle8017 wrote 15 hours 31 min ago:
Those wires are certainly long enough to be antennas.
buildbot wrote 15 hours 12 min ago:
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.
Damogran6 wrote 15 hours 34 min ago:
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.
UltraSane wrote 13 hours 28 min ago:
Also very low sales volume.
russdill wrote 15 hours 16 min ago:
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
wakawaka28 wrote 10 hours 25 min ago:
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.
OutOfHere wrote 16 hours 47 min ago:
Could've used a speaker and microphone with an appropriate
noise-resistant digital encoding.
0cf8612b2e1e wrote 15 hours 41 min ago:
That has to be abysmal bandwidth, right? How much data can you
practically transfer that way?
bmgxyz wrote 14 hours 12 min ago:
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.
TeMPOraL wrote 16 hours 17 min ago:
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.
XorNot wrote 15 hours 40 min ago:
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).
TeMPOraL wrote 15 hours 18 min ago:
> 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.
XorNot wrote 14 hours 9 min ago:
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.
nelop wrote 16 hours 45 min ago:
Ohhh that's a cool idea.
I love any project that uses audio.
Hizonner wrote 17 hours 2 min ago:
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.
wakawaka28 wrote 10 hours 30 min ago:
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).
bigfatkitten wrote 15 hours 39 min ago:
I donât see what diving into pointless semantics adds to the
discussion here.
MisterTea wrote 10 hours 8 min ago:
Because a company advertising security solutions who misunderstands
basic terminology is highly suspect.
Y_Y wrote 14 hours 19 min ago:
Good thing it's only important semantics that are being dived into
then
locusofself wrote 15 hours 53 min ago:
Whether you want to define it as a true air gap or not, this is
effectively how most "air gapped" clouds work, with diodes.
Alex2037 wrote 16 hours 16 min ago:
yes, but if your adversary is capable of exploiting a one-way diode
to RCE, you might as well just give up.
UltraSane wrote 13 hours 29 min ago:
Yes, this is about as secure as any network connection can be made.
magicalhippo wrote 15 hours 9 min ago:
Prepare to give up I'd say[1][2].
[1]
URI [1]: https://arxiv.org/abs/1503.07919
URI [2]: https://arxiv.org/abs/2012.06884
Alex2037 wrote 13 hours 32 min ago:
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,
wakawaka28 wrote 10 hours 26 min ago:
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.
tripletao wrote 9 hours 23 min ago:
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.
Havoc wrote 16 hours 23 min ago:
Unless the mossad is after you one way light based coms may as well
be
stronglikedan wrote 16 hours 34 min ago:
Last I checked, light does indeed cross gaps of air, so "air gapped"
is at least more appropriate than your comment.
hackstack wrote 16 hours 27 min ago:
By that logic, an open wifi router would be considered air gapped,
nâest pas?
nappy-doo wrote 17 hours 2 min ago:
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?
nelop wrote 16 hours 46 min ago:
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.
nancyminusone wrote 17 hours 21 min ago:
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.
tripletao wrote 8 hours 32 min ago:
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.
IncreasePosts wrote 16 hours 50 min ago:
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?
MisterTea wrote 10 hours 4 min ago:
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.
nelop wrote 16 hours 41 min ago:
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.
justincormack wrote 16 hours 34 min ago:
Pins on modern hardware like that are all bidirectional you set
the direction in software normally.
nelop wrote 16 hours 3 min ago:
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.
IncreasePosts wrote 16 hours 36 min ago:
Sorry, I didn't mean for your project, but for using a RS232 null
modem like OP suggested
nelop wrote 17 hours 17 min ago:
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.
c0nsumer wrote 17 hours 24 min ago:
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...
nelop wrote 17 hours 14 min ago:
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.
nelop wrote 17 hours 49 min ago:
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 wrote 17 hours 20 min ago:
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 wrote 17 hours 0 min ago:
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 wrote 17 hours 23 min ago:
Very curious what the hinted at issues were with using regular
unidirectional serial before introducing the pair of Pis.
nelop wrote 17 hours 9 min ago:
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 wrote 15 hours 51 min ago:
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 wrote 17 hours 12 min ago:
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 wrote 17 hours 5 min ago:
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.
DIR <- back to front page