Creating a bespoke data diode for air‑gapped networks
1–10 of 86 posts
Re: Creating a bespoke data diode for air‑gapped networks
#2I 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.
Re: Creating a bespoke data diode for air‑gapped networks
#3This 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...
Re: Creating a bespoke data diode for air‑gapped networks
#4I 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.
Very curious what the hinted at issues were with using regular unidirectional serial before introducing the pair of Pis.
Re: Creating a bespoke data diode for air‑gapped networks
#5Unless 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.
Re: Creating a bespoke data diode for air‑gapped networks
#6I 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.
Re: Creating a bespoke data diode for air‑gapped networks
#7Unless 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.
Re: Creating a bespoke data diode for air‑gapped networks
#8This 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.
Re: Creating a bespoke data diode for air‑gapped networks
#9I 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.
Very curious what the hinted at issues were with using regular unidirectional serial before introducing the pair of Pis.
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"
Re: Creating a bespoke data diode for air‑gapped networks
#10I 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.
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.