[toomuchtodo]

> 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.

https://www.schneier.com/blog/archives/2013/10/air_gaps.html

[commenter11]

It's really not all that complicated.

You get a couple of these Ethernet to 100FX converters: http://antaira.com/products/media-converters/unmanaged-conve...

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.

[toomuchtodo]

> You'll probably want to wrap your data in some error correcting code, too.

I've found that using hashes and sending duplicates of the data seems to weed out any transmission issues in a one way system.

[sdenton4]

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.

[vacri]

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.