One-Way Data Extraction For Logging On Airgapped Systems

If you want to protect a system from being hacked, a great way to do that is with an airgap. This term specifically refers to keeping a system off any sort of network or external connection — there is literally air in between it and other systems. Of course, this can be limiting if you want to monitor or export logs from such systems. [Nelop Systems] decided to whip up a simple workaround for this issue, creating a bespoke one-way data extraction method.

The concept is demonstrated with a pair of Raspberry Pi computers. One is hooked up to critical industrial control systems, and is airgapped to protect it against outside intruders. It’s fitted with an optocoupler, with a UART hooked up to the LED side of the device. The other side of the optocoupler is hooked up to another Raspberry Pi, which is itself on a network and handles monitoring and logging duties.

This method creates a reliable one-way transmission method from the airgapped machine to the outside world, without allowing data to flow in the other direction. Indeed, there is no direct electrical connection at all, since the data is passing through the optocoupler, which provides isolation between the two computers. Security aficionados will argue that the machine is no longer really airgapped because there is some connection between it and the outside world. Regardless, it would be hard to gain any sort of access through the one-way optocoupler connection. If you can conceive of a way that would work, drop it down in the comments.

Optocouplers are very useful things; we’ve seen them used and abused for all sorts of different applications. If you’ve found some nifty use for these simple parts, be sure to drop us a line!

23 thoughts on “One-Way Data Extraction For Logging On Airgapped Systems

  1. Old 10-base-T Ethernet cards had a 15-pin D connector to attach a “media access unit” (MAU). You could get them for thicknet (RG8 CoAx), thinnet (RG58 CoAx), 10BaseT (RG45) or fiber optic.

    We needed to be able to send commands to a classified system from an unclassified system.

    We used fiber optic MAUs, disconnected the TX fiber on the classified device and sent commands to it using UDP. Point to point there was no risk of collision, so UDP was reliable for our purpose.

    1. Ah, the fiber optic data diode. UDP is your friend.

      For more modern systems with RJ-45 connections, we’d use fiber optic ethernet media converters. Weird setup since the media converters needed to see light on RX to believe they had an active line so you had to hook up a 3rd converter to provide it.

    2. You don’t need a full-blown MAU to do this. Just the TX pair from the usual RJ45 works fine, even at 100 Mbps.

      We needed to send 100 Mbps from a rotating platform. Slip rings wouldn’t do the speed. Optical couldn’t do the rotation. COTS RF solutions at the time were too slow or too expensive. A simple capacitive-coupled balanced “antenna” (non-contact coupler) worked, with a bit of signal conditioning. We did have a 115200 bps backchannel over a slipring to control the comms and send checksums/retries, but the bulk transfer was, like yours, plain old byte UDP packets. The checksums weren’t needed: Our bit error rate was zero (unmeasurable).

      That was turn of the century. They’re at 40 Gb/s now, and the couplers are far more sophisticated. I don’t know what magic was conjured to make that possible, because it isn’t, on paper.

  2. I’m all in favor of HaD taking up the mantle of 2600 magazine, so this isn’t a complaint, but obviously this does defeat the (questionable) concept of an air gap, which is to make access physically impossible.

    There could be information leaked in the log data or a side channel that was supposed to be secret, or perhaps could be used to acces the Raspberry Pi through the wifi interface that it has, and from there access the target system, etc. It’s unlikely, but you can’t rule it out, and then why not just make life easier by networking the thing and hoping your firewall is up to the job?

    1. If this optocoupler setup breaks the air gap, then so does attaching a monitor to the machine does so as well. Heck, by your logic, if a computer has any way to affect the outside world (i.e do anything), then it isn’t air gapped.

    2. Yes, log data can leak sensitive info out, but if your threat model is an attacker gaining remote control over a device, this is just as secure as not having anything between them at all. Even if you got root access on the networked Pi, you can’t do anything on that pin to influence the secure Pi

    1. If you design an airgapped protocol, maybe not sending commands along the sensor data and not executing arbitrary data might help. It’s easy to tokenize, set max length, check if data is float or integer and then save it. I really find this bothersome to assume that the creator would even design such an implied footgun.

  3. If you really think this is not enough and need more airgap then have a display on the safe machine and a camera with OCR on the logger. You can even separate the two machines with bullet proof & water proof glass…..

  4. Used an opto isolator? He took the term air gap to literally. Anyone who actually knows anything about electronics would know that using a UART aka RS232 IC TX pin is an output only pin. The opto did nothing to help the matter.

  5. You can still exfiltrate/leak sensitive data. During the LED ON phase any fluctuation on the power line due to e.g. cryptography in another task can be detected on the receiver side.

    1. Eh, I’m not so sure. This has the same attack vector as someone putting a current/voltage sensor on the pin. Pretty unlikely. Even still, the sample rate is so high for a CPU I really doubt there’s any practical way anyone could do that in a meaningful way anyways especially if there are any capacitors inbetween. I’d love to read an article where someone has pulled this off and gotten anything out of it in a plausible scenario. I just doubt it.

  6. Could you exfiltrate data through the optocouplers, on top of the serial protocol? Probably if the PIs talk directly to the hardware. Optocoupler probably supports higher frequencies than serial.

    1. Should hook up dumb serial chip, that can not be exploited by the PI. Optocoupler driven by the PI is allowing the complex system, that one is worried about, a direct control, allowing attacker to add protocols on top of the serial.

Leave a Reply to RWoodCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.