You normally use such a scheme to pass data from the more critical to the less critical system. For example in nuclear power plants (that's where I know this scheme from) your low-safety systems can use data acquired by a highly safety relevant system (e.g. to display the pressure, temperature and power generation of the reactor core without being able to influence the safety systems that primarily acquired the values).
This sounds almost as if you configured a network adapter to only send and not receive, but you used "optics", so I'm guessing you refer to some sort of fibre-based device that actually impedes light to go in the other direction, and thus the security is via physical means?
Google for something like "fiber converter". Normally if you run a copper ethernet cable between two buildings its a lightning magnet and next thunderstorm you'll get a big enough ground loop to blow up the gear on one side or the other if not both. So for $50 (seriously) you can buy a gadget thats been around for at least 20 years that has ethernet on one side and two fiber SC connectors on the other side of the box and you run non-conductive fiber between the buildings and sneer at the lightning gods whom will simply take their vengeance in another way LOL.
All you need to do is only run one fiber jumper, the TX from one side to the RX on another, not the two you're "supposed to" use. SNMP traps run on UDP and work just fine, old style syslog runs over one way UDP too. Note that your production/secure network can DDOS your IT/insecure network if enough people on the secure side try to use a DNS or NFS server on the insecure side, it'll just spam packets forever and never get its response, so its not like firewalls are completely pointless.
In the really old days we'd do something similar to RS-232 cables, physically yank out pin 2 or pin 3 (conveniently they swapped TX/RX on 9 pin vs 25 pin RS232). PPP negotiates connections, SLIP doesn't care and works great.
(edited to add another thing we did back when 10 meg ethernet was "new" and just replacing thinnet and thicknet, was pulling the approriate pins for TX, before auto negotiation existed, before 100 meg ethernet even existed, you could get away with that... I suppose if you had two smart-ish switches that could be forced to 10 meg no negotiation, you could do this today...)
Also there were production machines that output error, alert, and log messages to theoretically directly attached parallel port printers and there also existed converters that could go from parallel port to serial port (presumably for serial port printers, which really did exist in the 80s), which makes a pretty good unidirectional connection from a secured device to a semi-secured logging server. Bidirectional parallel ports didn't really exist until maybe 1990 or so and never did standardize, not really.
I made a lot of money implementing this kind of stuff in the 90s. It was fun.
> so I'm guessing you refer to some sort of fibre-based device that actually impedes light to go in the other direction, and thus the security is via physical means?
Correct. To simplify, imagine a diode on one side and a photodetector cell on the other. On a microcontroller, this would be an opto-isolator (http://en.wikipedia.org/wiki/Opto-isolator).
Of course, the higher levels of the OSI protocol you're using need to support this sort of physical layer. Its typically used on very primitive, low-bitrate connections (sensors mostly, although I've seen it used in highly sensitive installations using scada equipment).
Bruce Schneier has a great piece on air gaps. I've included a link to it below.
Then you hook them up with just one fibre strand (instead of the usual 2).
You obviously can't use TCP over that since that requires a 2-way connection, but UDP works just fine. You'll probably want to wrap your data in some error correcting code, too.
sure, at a communication complexity of 2N+k, where k is the hash size.... Error correcting codes allow much shorter error-free communications, with lower probability of failure than your method.
Consider an N bit stream of data, with a probability mu of any given bit being flipped. Then the probability of your stream containing an error is gamma := 1-(1-mu)^N. Since you're sending the identical stream twice, there's a 1-(1-gamma)^2 chance that your overall transmission is unrecoverable. The hash will tell you that the transmission failed, but not how to correct it. Furthermore, there's a probability that your hash has a bit flipped somewhere, too...
An error correcting code makes a guarantee that if up to m bits are flipped, the original message can be recovered exactly. A Reed-Solomon code can correct up to m errors while adding just 2m bits to the message length; even with a pretty conservative upper bound on the number of expected errors, this should be way less than 2N+k.
I really don't understand why Schneier is so popular. The article in the link doesn't have a clear audience - some of it is written for complete security naives, other parts are for power users ('turn off autorun services'), and some fundamental parts are flat-out wrong for both audiences ('you can't set up a computer without connecting it to the internet') or misleading (implying a 'small' USB pendrive of only 1GB will help).
And if you want to 'leave no space', why fill up a disk with 'random files' rather than just a single file that uses up all the space? If you're going to the lengths of encryption + airgap + cloudantivirus (!) + etc, you're a power user at this point, so why not just consume all space rather than just collect together files?
And hell, if you're being that paranoid, then use the paranoid OS for your desktop, OpenBSD. Why go to all the effort in the article and not take the extra step to get familiar with an OS that has an earned reputation for security, and that most exploit-writers don't target? I mean, OpenBSD does OOo and pdfs as indicated in the article - what's this airgapped PC going to be doing that requires Windows in particular?
It's ironic that this author people turn to for commentary against 'security theatre' writes articles doing the same.
How can that ever work? If you're using TCP/IP, you always need to receive an acknowledgement that what you sent actually got to the destination, right?
You're right, TCP/IP wouldn't work. UDP would work fine though, as well as anything lower level. You'd just continually send packets at a rate that was slow enough that there'd be no reason that the other side would drop them.
Imagine that the designers want to send information about the plane's expected arrival time to the in-flight entertainment system. You could send a packet once per minute, without any knowledge of whether or not anyone is even listening. If an update is missed, it doesn't matter since the information rapidly becomes stale.
Maybe it's a variation of TFTP (which uses UDP) that doesn't ack the connection or the file? That would be rather amusing, broken TFTP sold as a security app.
I read about one of these devices once, vendor info said that it runs a small and "verified" kernel (probably seL4 or something like that) that does the TCP stuff and took care not to let any real information flow in the other direction.
Apart from FTP, it support SMTP, probably others as well that I forgot.
It did not sound very convincing to me. Even if the kernel is totally secure, you could probably have a side channel via ACK timing?
1) The system can't be compromised through input data.
2) There's no other output mechanism by which an attacker could retrieve data (or watch the plane crash, which technically counts as output).
I'm not sure I buy the idea for contexts where a genuine security airgap is required.