[minot]

> An air gap or air wall is a network security measure that consists of ensuring that a secure computer network is physically isolated from unsecured networks, such as the public Internet or an unsecured local area network. It is often taken for computers and networks that must be extraordinarily secure. Frequently the air gap is not completely literal, such as via the use of dedicated cryptographic devices that can tunnel packets over untrusted networks while avoiding packet rate or size variation; even in this case, there is no ability for computers on opposite sides of the air gap to communicate.

The case above is an example cited as a life-critical system: > Computers used in aviation, such as FADECs and avionics

https://en.wikipedia.org/wiki/Air_gap_(networking)

[toomuchtodo]

You can also accomplish a one-way airgap using optics that can only pass data in one direction.

[teacup50]

The security of such a thing assumes that:

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.

[cnvogel]

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

[teacup50]

Ah! Thanks, that clarification makes way more sense.

[saganus]

Can you elaborate a bit more please?

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?

[VLM]

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.

[toomuchtodo]

Thanks for the informational post!

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

[saganus]

I love HN!

Thanks for all the useful responses. I always learn something new by reading the comments :)

[atonse]

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?

Or does raw fiber use different protocols?

[jewel]

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.

[jonah]

The GP probably means an opto-isolater.

It obviously wouldn't work for carrying something like TCP/IP but rather much lower level signaling.

http://en.m.wikipedia.org/wiki/Opto-isolator

[karambahh]

I was at a security trade show earlier this year and some companies were marketing "FTP diode": one way FTP transfert.

I did not have time to discuss it with them, but how a tcp based protocol could be "one way" just does not make sense to me...

[kbenson]

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.

[geococcyxc]

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?

[geraldcombs]

This sounds an awful lot like a standard FTP server configured with a write-only directory.