22

What would be a way to transfer files in one direction from internet-facing computerA => air-gapped computerB to protect the files on computerB from unauthorised disclosure, short of using an expensive data-diode?

Requirements

  1. The data transfer must be continuous. (cable is ok but not a USB flash drive)
  2. Only the confidentiality of data in computerB is important. There is no need to protect the integrity of data in computerB.

Consider that computerA may be at a risk of being compromised. What would be the best way to transfer data (mostly pdf files) in one direction? I'm looking for a solution that mostly protects against remote attacks (i.e. confidential files end up on compromised computerA) rather than local attacks (attacker is a few metres from the setup).

10
  • you could make a folder for the sensitive info with write-only perms. you could also put up a 2nd internet-connected computer, that shares a non-network connection with B, like a serial port, and use a small script to push data over the serial connection into a file on B. That would render OS/malware/network exploits moot, at the cost of complexity and bandwidth. Commented Dec 14, 2020 at 17:52
  • 1
    There is no need to protect either computer. Unidirectional transfer is required to protect the confidentiality of files in computerB - which is what data diodes typically do. Commented Dec 14, 2020 at 19:13
  • 20
    This is a classic XY problem. You want to protect Y (the files on computerB), so you explore securing X (the file transfer process from computerA). But these concepts do not connect. You want a simple firewall on computerB. And computerB is not air-gapped if it is connected to the network... Commented Dec 14, 2020 at 19:23
  • 3
    @Doug: OP only seems to care about B's exfiltration, not corruption. Commented Dec 15, 2020 at 22:10
  • 8
    I made something like this using a sequence of QR codes as a "modem" to pass one-time-pads between phones. A good webcam pointed at a good monitor should be able to pass the full 4kb per code, probably at a rate of at least 10hz, maybe more depending on framerates and CPU. It's not the simplest method, but it might be the cheapest since it uses existing hardware. Commented Dec 15, 2020 at 22:24

5 Answers 5

39

I've seen this implemented many times in secure environments:

Simply connect the two computers via optical fiber and disconnect one side of the fiber.

That guarantees your one-way connect.

Protocol wise, the connection uses UDP protocol with a:

  1. Start-Block
  2. Data-Block
  3. Stop-Block
  4. Checksum-Block

Typically the Start and Stop are whole files, not chunks.

The Receiver simply checksums the data and compares with the checksum sent. If it matches, you're done. If not, the receiver indicates an error that has to be manually checked with the User having to manually re-send because there is no automated feedback.

This simplistic approach works quite well because with a direct fiber one-to-one connect, classic concerns about UDP mostly don't happen.

  • Order is guaranteed because it's completely sequential.
  • Reliability while not assured, is extremely high without network contention.
  • Verification only requires a simple checksum.

Some systems opted for multiple retransmissions as a simplistic error correction but errors are rare with a direct connect.

6
  • Exactly. Given the bandwidth of a typical optical link, it's easy to send the same data 1000+ times (with a grown-up hash instead of a short checksum that can fail to detect some types of corruption) and thus practically eliminate the potential failed transfers. Just make it resend each data block every minute for 24 hours or so and you get something that's very resilient against all kinds of issues. Commented Dec 15, 2020 at 13:00
  • 14
    @user253751 Not just for eye safety, but also to prevent said expensive transmitter from getting ruined by lots of dust getting in there. Commented Dec 15, 2020 at 15:01
  • 6
    Not sure if this is still relevent, but back when I was implementing this type of thing with fibre optic network cards nearly 20 years ago, they needed to see a carrier on the Rx port in order to send data out the Tx port. This meant you'd need a second card on your sending box looping back its Tx to the Rx of the card that you want to send data to the other box with. Commented Dec 16, 2020 at 2:33
  • 1
    @user253751 Have you ever used optics IRL? They are incredibly low power. Your typical 10km/40km SFP+ module has a lower IR radiant energy density than a light bulb. Don't spread FUD about laser safety Commented Dec 17, 2020 at 5:55
  • @user253751 I said "radiant energy density". If you focus a beam, the energy density goes up while the power stays the same. In other words, I've taken into account that the beam is more concentrated. btw the output is not totally invisible; Every module emits a small amount of visible light. This is a manufacturing defect, but it's very useful for debugging. Look for it the next time you're in a data center. To be clear, I'm talking about optics that you plug into switches. Higher power optics exist, but they are externally powered. That's probably what your instructor was talking about. Commented Dec 17, 2020 at 14:59
21

Use a serial port with the TX pin removed on computer B.

You can send the data but no matter what happens you physically can't get it out of computer B without the TX pin.

6
  • 14
    Don't remove the pin, remove the wire in the cable. You never know when you might want to use that port for something else later. Commented Dec 15, 2020 at 14:32
  • I've done this on several occasions, it's easy and inexpensive. Your transfer speed is a bit limited, but still plenty fast for many use cases. Commented Dec 15, 2020 at 16:04
  • 3
    @user253751 I had intended to mean that the pin in the cable be removed, but that is a good clarification. For astandard PC serial port, the cable usually has pins and the PC side is usually a sockets. Commented Dec 15, 2020 at 16:43
  • I don't think you need to remove TX, which could be needed for flow control. An exploit that usefully alters an already-running program that has exclusive access to B's serial port, as well as a new incoming serial handler on A to exfiltrate, seems basically impossible. If eve could devise that, you might as well give up. Commented Dec 15, 2020 at 22:14
  • 3
    @dandavis The TX is not needed for flow control, flow control is done over pins RTS and CTS, which could be skipped like the other pins. If missing, the transmitter doesn't know if the target has enough space in its buffers. You really only need GND and RX with serial on side A, and TX and GND at the other side. (Source: I have 2 USB to serial adapters laying around here, and this is the bare minimum needed to make 2 devices talk) Commented Dec 17, 2020 at 16:38
9

You can use a packet filter and a custom UDP service to make file transfer, but I believe you want something that isn't even needed.

Have Computer B sit behind a router with firewall configured. The firewall allows traffic in, but drops traffic out. That's why you need an UDP service, as TCP would have to send confirmation data out, and that's forbidden.

Your UDP service would have to receive the filename, the file size, and a Merkle tree with the hashes of the chunks. You need to cut the file in small chunks because UDP does not guarantee the order, or even that the packets will even be received. Every chunk would need to have its sequence order, size, and hash. Send the chunks one after the other, with a delay between each one.

On the receiving site, the service will have to get all chunks, hash them, put them in order, and calculate the Merkle tree to see if the file was sent without problems. If the file is in order, save it. If not, discard it because there's no way to tell the sending side that the file was not send correctly.

3
  • You could actually also use TCP if you configure the firewall to only allow outbound TCP packets without a payload. While in theory that could create a side-channel to exfiltrate data from B, actually pulling that off by gaining remote code execution on B through a single-purpose unidirectional dumb link like this is likely nearly impossible. Commented Dec 16, 2020 at 10:14
  • 3
    @TooTea That sounds painful to configure. Even if you only allow SYN/ACK, TCP is complicated and has plenty of slots where you can exfiltrate data such as the sequence number. When OP said "air-gapped", I'm pretty sure he is referring to a physical barrier that prevents exfiltration even if B is compromised. Commented Dec 17, 2020 at 6:03
  • A router (that could be any computer, really), or a managed switch that supports access-lists that would let you drop everything received on computer B's port. Of course the router or switch should not allow any management access from either A or B, and any possible bugs in their software would become part of the problem. Commented Dec 18, 2020 at 14:01
9

You can try "unidirectional" network cables: https://electronics.stackexchange.com/questions/279257/implement-send-only-one-way-ethernet-cable

A speedy DIY data diode can be built for 100-200 bucks with a pair of media converters + a fiber optic splitter. As software, you can use udpcast. You can also find some other DIY setups including software on the webs. Note that a data diode won't protect B against attacks. (Excluding side channels) it will only prevent data from flowing back.

There is also some ongoing project: https://www.thehaguesecuritydelta.com/projects/project/99-open-source-data-diode But nothing has been published as far as I know.

Also if A is compromised how do you "trust" the data coming from A?

3

Do not try to write your own. Use a protocol that already does this.

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.