1

Is it possible to have an air-gapped system which can send and receive files?

From a high level perspective, I can't seem to figure out how this can work and I am starting to think it is impossible. But before I give up, I thought I should ask the experts here if it is possible or not.

I have tried using USB drive, one way ethernet cables, public-private key pairs, web cams, ocr etc, but I can't seem to work it out.

How about using a system similar to the blockchain? The blockchain can send and receive data and remain secure, as in an off line computer can sign a transaction where the private key is safe, then the signed transaction can be broadcasted on an online computer, which means the off line private key never gets connected to an online computer.

Can this model somehow be adapted to make it possible to send and receive files in an air gapped system?

When I say "system" I mean I don't mind if I have to have multiple computers in the system to make air gap sending/receiving possible.

Here is a quick high level diagram. Any method I think of to send files between OF1 and OF2 (red dashed line) seems to compromise everything.

enter image description here How do I send encrypted files from OF1 to OF2 without compromising everything in the system? So far, I have not be able to think of a solution.

The difficulty for me is the red dashed line. How do I transfer a file between OF1 and OF2.

Is it even possible?

oshirowanen
  • 705
  • 3
  • 10
  • 21
  • I think you need to explain your use case in more detail. Physical or virtual air-gaps are used to isolate some important system/network from the less secure systems/networks around and the goal is to not allow any arbitrary bidirectional data exchange because this would essentially bypass the air-gap. Based on this your question does not make much sense for me since it basically asks for arbitrary bidirectional data exchange. You only discuss the methods on how the exchange might be done - but the important part is less the physical exchange but the restrictions on what gets exchanged. – Steffen Ullrich May 18 '19 at 19:00
  • @SteffenUllrich, further details added. – oshirowanen May 18 '19 at 19:30
  • Thus looks more like a use case for data diodes or similar. See [wikipedia: Unidirectional Network](https://en.wikipedia.org/wiki/Unidirectional_network). I don't see how blockchain can help here since it requires a data exchange from the air-gapped system (which writes a new entry on the chain) to the rest of the network (which reads the new entry on the chain). If this would be fine than propagating a simple encrypted message would be possible too and also easier. – Steffen Ullrich May 18 '19 at 19:35
  • @SteffenUllrich, the blockchain was just a wild idea I was throwing into the mix only because I liked how its possible to sign messages offline without the private key ever reaching an online computer. Would have been nice if that system could be adapted for file encryption with air gapped computers, but it seems that thought was just a wild shot.. I will look into the data diodes. Thanks. – oshirowanen May 18 '19 at 19:47
  • @SteffenUllrich, I don't think a data diode can work in this scenario. If OF1 is compromised and I have a data diode between OF1 and OF2, the data diode would just end up sending a possible compromised encrypted file from OF1 to OF2. I understand I can use a data diode from ON1 to OF1 and from OF2 to ON1. But I need some other method of sending a file from OF1 to OF2 when OF1 is considered compromised. – oshirowanen May 18 '19 at 19:54
  • Let me rephrase this: you need to send a file from the possible compromised system OF1 to OF2. This file is already decrypted since only OF1 holds the key for decryption. Given that OF1 is possibly compromised the file it sends to OF2 is therefore possibly compromised too and might thus cause a compromise of OF2. Sound like a pretty dangerous idea to me, no matter what method is used to transfer the files, i.e. no method of transfer will magically make the possibly harmful file be safe again so that OF2 can accept it without any harm done. – Steffen Ullrich May 18 '19 at 20:06
  • @SteffenUllrich, it does seem impossible. Thanks. – oshirowanen May 18 '19 at 20:16
  • @oshirowanen Looking through this more, it might be possible, if you use authenticated encryption and can be sure that it is impossible to compromise a system through the decryption and authentication code. – forest May 19 '19 at 03:27
  • Is OF2 nothing more than a router of sorts which sends raw encrypted data from OF1 to ON1? Does it not process the received data in _any way_ whatsoever? If so, then you may be able to do this safely, as long as you can ensure that it cannot be compromised via the protocol it uses to connect to ON1 (e.g. assume Ethernet and TCP/IP drivers can be exploited). Also, is the entire purpose of this setup to backup data from the potentially-compromised OF1 without compromising other systems? – forest May 19 '19 at 03:30
  • Without knowing your exact threat model, it sounds to me like the purpose of OF2 is to be a sort of buffer to ensure that a compromised OF1 cannot covertly transmit data to ON1 through side channels or other covert communication methods. If that is the case, then I believe there _are_ ways to encrypt data and allow another device (like OF2) to verify that it is encrypted correctly without needing to know the encryption key. – forest May 19 '19 at 03:34
  • @SteffenUllrich I don't think it is impossible if OF2 doesn't process the file's data at all. If my guess of OP's threat model is correct, then it would be possible to use OF2 as a buffer to prevent covert data exfiltration between OF1 and ON1, without risking OF2's integrity at all. Obviously OF1 could send plaintext through a side-channel or send it unencrypted, but OF2 can be made to ignore that safely and refuse to relay the data to ON1 without risking being compromised itself (assuming it starts out uncompromised). – forest May 19 '19 at 03:36
  • @forest: While the full use case of the OP is still not clear for me (and is this a use case relevant in practice at all) what he describes contains no distinction between good and bad data from OF1. This means either OF2 will encrypt and send all data from OF1 to ON1 and thus enable arbitrary data exfiltration. Or it will somehow process the data to verify that these are allowed to be send to ON1 or it will at least log the data it had transferred (which then gets processed when reading the log file - might contain XSS etc if viewed in the browser). But again, the real use case is not clear. – Steffen Ullrich May 19 '19 at 05:30
  • @SteffenUllrich You're right, the full use case is a bit vague. However the diagram he gives shows OF2 as only receiving encrypted data, which means all it has to do is verify that the data is supposed to be sent (genuinely encrypted). There is a solution for that which does not require accessing the data, as I mentioned in my answer. But you're right, I can only go by my assumption without further information from OP. – forest May 19 '19 at 06:01
  • *"... shows OF2 as only receiving encrypted data"* - I understand the diagram different. Only OF1 has the private key to decrypt the data and only for OF1 it is said that it receives encrypted data. Only for OF2 (and not for OF1) it is said that it sends encrypted data. For me this looks like OF1 decrypting the data from ON1 and sending these plain data to OF2. OF2 can encrypt plain data and send to ON1. Anyway, it is totally unclear who generates data and who processes plain data. – Steffen Ullrich May 19 '19 at 06:56
  • @SteffenUllrich You're right, I see how ambiguous this is. I've marked as unclear. – forest May 19 '19 at 07:04

1 Answers1

1

Assumptions:

  1. OF1 is compromised and wants to send unencrypted data to ON1, which wants to receive it.

  2. OF2 is not currently compromised and wants to prevent ON1 and OF1 from conspiring.

  3. OF2 is unable to analyze the plaintext to ensure it is safe without getting compromised.

There are two ways for OF1 to covertly send data to ON1. First, OF1 can send it unencrypted data and hope it relays that unencrypted data to ON1. Second, it can use a covert channel such as timing delays and hope that OF2 faithfully reproduces any variation in transmission latency or time of transmission.

In this case, You must do two things. The first thing you need to do is ensure that OF2 is capable of verifying that the data it has received has been encrypted with the correct public key, without knowing the corresponding private key or the plaintext. There is a technique which can accomplish this called a zero-knowledge proof of encryption. It is possible to verify this with very simple code (potentially even from a formally-verified library) that you can assume is not vulnerable to exploitation when parsing untrusted data. This is a lot easier to do with cryptographic code than it is to do with other code that parses complex data. You should have a good understanding of cryptography before attempting to do this.

The second thing you must do is turn OF2 into a buffer which blocks all covert communication methods. This is easy enough if it transmits data on a schedule or on-demand, for example. If OF2 is a buffer which collects data from OF1 and only sends it to ON1 at scheduled times, it is impossible for OF1 to send covert data through a timing side-channel by varying when or how fast it transmits data. In order to prevent covert information from being exfiltrated in the size of the data, it should be padded to a specific size. From the perspective of ON1, it always receives a specific amount of unreadable, encrypted data at a specific, predictable time (on a schedule, or when you want to send the data, not when OF1 does).

The actual protocol you use for the red line doesn't matter very much, as long as it is extremely simple. You should assume that Ethernet interfaces can be compromised, and that OCR scanning software is vulnerable. A possible solution would be a very simple serial protocol, such as RS-232.

forest
  • 64,616
  • 20
  • 206
  • 257
  • Thank you for this. The only assumption which is different from what I had in mind is that OF1 does the decrypting and encrypting. Does this makes things any easier? My concern is that OF1 is compromised, so is it safe to use it to encrypt? – oshirowanen May 19 '19 at 19:10
  • @oshirowanen That's part of my assumption as well. If you take the measures I mentioned in my answer, it should be safe to use OF1 to encrypt, even if OF1 is compromised and wants to send unencrypted or improperly encrypted data. – forest May 19 '19 at 22:58