Ethernet Wiring Through Hostile Territory?

GoogleDidntFindIt asks: "I need to connect a terminal to a server which contains very sensitive information. Unfortunately, the terminal is about 200 feet away from the server. The server (which even includes a 'self destruct' device) and terminal are both in highly secure areas of the building, but the wiring will be in uncontrolled areas. What should I do to keep people from tapping or monitoring the wire?" Is there any way a conduit can be wired with an alarm which goes off when it's integrity has been violated?

"Heres a basic description of my situation:

• A new wire/fiber/cable/whatever will be run and I can use any sort of conduit I want.
• A potential attacker may have several days of undetected access to parts of the wire/conduit and may have sophisticated fiber-optic tapping equipment (which can tap a fiber without cutting it).
• I can physically inspect the conduit/cable/wire once a month.
• Ideally, the system would also notify me of a majority of successful attacks (or, even better, disconnect the line).

I'm aware of IPSEC and other encryption systems, but they aren't suitable for this project - I'm looking for systems which address physical security and protect against traffic analysis."

Comments

Conduit under pressure.

[jvhaarst]

How about putting the conduit under pressure/vacuum and shutting it down when there's a leak ?
A waterhose with a waterprrof glassfibre should do the trick.

Fibre + steel + pressure + ...

[loony]

Depends on how much you want to spend, but I'd go with a fibre connection - makes it more difficult to tap.... Put it into a steel pipe, mostly to protect the fibre. Then an thin insulating layer (the thinner and fragile the better), a layer of copper (like the shielding of a coax cable) and a final protective layer. Pressurize the steel pipe and monitor the pressure, and also put a little voltage between the steel pipe and the copper. That way the fibre is well protected against accidental, mechanical damage, and its pretty difficult to first get rid of the copper layer without it touching the steel pipe, and even more difficult to open the pipe to get to the fibre without changing the pressure... Costs you probably quite a lot, but I'll bett my lunch that unless you're up against the government, you'll be happy with it.

There's a government standard here-- TEMPEST

[Jason Cwik]

I remember reading about TEMPEST standards from the government. The documents were (mostly) declassified recently and have standards for wiring sensitive (RED) data connections in different environments-- all the way to battlefield conditions.

Plus, you have some CYA protection here since it's a predefined standard!

http://www.eskimo.com/~joelm/tempest.html

http://www.fas.org/irp/program/security/tempest.ht m

... but I still like the chain link fence idea with guard dogs ...

2 possible methods for detection of tampering

[addikt10]

Neither will detect a successful tap, but inducing an electrostatic charge on the conduit (a la the lamps that you touch anywhere on the base to activate/deactivate) would let monitoring systems know if someone touches the pipe to set off an alarm and shut down communications, but would open you up to an easy DOS.

The second is an OTDR (optical time domain reflectometer) - this will easily detect changes in the fiber layout, and will also tell you exactly where the tap/modification occurred.

Basically, an OTDR sends a pulse of light and looks at the reflection(s) over time. It will show bends, nicks, etc that occur in the fibre.

Re:To avoid traffic analysis, use 100% bandwidth

[karlm]

Precisely! Physical security and encryption WILL both be broken. With physical security, you can pretty much make the lower bound on the time required somewhere in the days to months range. With encryption you can pretty much make the lower bound on the time required somewhere in the decades to millenia range. Of course, both of these estimates rely on lots of assumptions.

It seems to me that you want to wrap your end-to-end encrypted tcp traffic (ipsec) with a synchronous link encryped protocol that sends garbage when it's not sending data. These sorts of link encryption devices exist (at least they used to). I imagine that modern versions exist that use AES, twofish, serpent, or RC6 instead of DES. (I've heard good arguments for each of these AES finalists. If you have the choice, you won't get blaimed for agreeing with NIST.)

In any case, you really need to use ipsec in addition to your link encryption layer. Adding physical security may be a good idea as well, but traffic analysis-resistant link encryption has been arround for decades.

If in the unforseable event that you can't find a supplier for link encryption, it sound like you may have the budget to develop your own link encryption. Authenticated key exchange is the easiest part to screw up, so go for manually entering the keys into the boxes. (If an attacker has physical acess to the link encryption device, assume you've already lost the traffic analysis game.) For link encryption, you probably want to use a self-syncing mode of a block cypher such as CFB Make sure your block cypher is suitable for CFB mode operation. Make sure to use gpg's crypto-strong random output function or something similar to generate your keys. You should rekey at least as often as you sheck the physical integrity of the line.