Data diode for high security

[Cubic Earth]

I've been thinking about how I could construct my own data diode.  I know there is a lot to consider, but right now I am just curious about the physical layer.

Does anyone know if it would be possible to splice into some cat-5 cable a few actual diodes and still have the signal pass?  Or would they mess up the impedance, or something like that.  I know there are transmit and receive pairs, but perhaps they could be remapped somehow.  I would be cool if you could actually just buy some diodes and make your own one way cable.

[1714630302]

1714630302

[1714630302]

1714630302

[1714630302]

1714630302

[1714630302]

1714630302

[1714630302]

1714630302

[1714630302]

1714630302

[mitty]

Not sure how to do it with cat-5, but with fiber you can simply leave the tx or rx cable disconnected.  You need to make sure the network switch won't automatically re-map tx/rx for performance gains though. (I hear this is done on some newer switches)
This is sometimes used in high security settings where a machine can receive from a public data source but can't leak data back out to that source.

^ I haven't done any of this in practice; just heard about it so there could be inaccuracies.

[Foxpup]

With 10/100BASE-T over Cat-5 (but not 1000BASE-T, which uses all four pairs), just disconnect the transmit pair (pins 1 and 2, either green and green/white (T568A) or orange and orange/white (T568B)), and you will no longer be capable of transmitting. Then put your card in promiscuous mode (since you obviously won't be able to establish a connection), fire up your favourite packet sniffer and you're done. Note that you may experience unavoidable data loss, as you will be unable to request that dropped packets be retransmitted.

[Cubic Earth]

With 10/100BASE-T over Cat-5 (but not 1000BASE-T, which uses all four pairs), just disconnect the transmit pair (pins 1 and 2, either green and green/white (T568A) or orange and orange/white (T568B)), and you will no longer be capable of transmitting. Then put your card in promiscuous mode (since you obviously won't be able to establish a connection), fire up your favourite packet sniffer and you're done. Note that you may experience unavoidable data loss, as you will be unable to request that dropped packets be retransmitted.

I thought about that technique, but I was wondering if some hack could remap the pins?  I know it would be really hard to pull of, but there are some very determined adversaries out there.  So I wondering if I do as you described, but also spice some actual diodes into whatever pairs, either the tx or rx, that are hooked up.  Then even if the pins were remapped the electricity could not flow backward.

I can see fiber being more secure though.  Even with diodes in copper, just because the electricity wasn't flowing backwards wouldn't stop information from leaking out.  You could always vary the electrical load in a specific way and the sending side could detect the difference.

[Foxpup]

I thought about that technique, but I was wondering if some hack could remap the pins?  I know it would be really hard to pull of, but there are some very determined adversaries out there.

The only such hack is Auto-MDIX (which swaps the transmit and receive pairs if you used a patch cable where a crossover cable was required or vice versa), which won't work if only the receive pairs are connected. If you're worried about "determined adversaries" (just who do you expect to be pissing off, exactly?), worry about such techniques as time-domain reflectometry, which will detect any devices connected to a network cable even if they are not actually transmitting anything.

So I wondering if I do as you described, but also spice some actual diodes into whatever pairs, either the tx or rx, that are hooked up.  Then even if the pins were remapped the electricity could not flow backward.

Electricity doesn't work the way you think it does. The direction of current flow has absolutely nothing to do with whether you're transmitting or receiving a signal. You seem to think that signals are transmitted by "pushing" electrons down a wire, where they are somehow "collected" by the receiver. This is not how electricity works. Electricity works with voltages. Electricity flows when there is a difference in voltage between two points, and flows from the point of higher voltage to the point of lower voltage (it actually flows in the reverse direction, but nobody will know).

In a twisted pair cable, transmitting a signal is done over a pair of wires, where one wire of the pair (specifically, the white-striped one) has a positive voltage and the other (the solid-coloured one) has a negative voltage. This causes an electrical current to flow through whatever the two wires are connected to. These voltages can be turned on or off, causing the current flowing through the device the wires are connected to to start or stop, and this is how a varying signal is transmitted. Note that with this setup, a single pair of wires can only transmit in one direction, so in order to send signals and receive them, two pairs are needed, hence why you have a "transmit" pair and a "receive" pair. Cat-5 actually has four pairs, but the other two pairs are not used in regular Ethernet, and hence can be used for other purposes, eg, power over Ethernet, but that's another story.

Note that it is trivial for the transmitter to reverse the voltages, but this would not actually make any difference (actually, it makes the difference that your network card simply won't detect the signal at all because it's only designed to detect current flowing in one direction, not the other; but it would be possible to modify the card (with a full-wave rectifier) so that it could detect it, and then it really would make absolutely no difference).

[saddambitcoin]

sorry for noob question, but what does a data diode do?

[Foxpup]

sorry for noob question, but what does a data diode do?

It is a type of network connection that allows you to receive data, but not transmit data. It's used to prevent accidentally leaking sensitive data over the network (which also requires the use of a second, more secure channel to acknowledge receipt of data) or to intercept network data without being detected.

[Cubic Earth]

The only such hack is Auto-MDIX (which swaps the transmit and receive pairs if you used a patch cable where a crossover cable was required or vice versa), which won't work if only the receive pairs are connected.

A firmware hack couldn't remap the pins?

If you're worried about "determined adversaries" (just who do you expect to be pissing off, exactly?)

Jeeze, the only friend who I called about this basically asked me the same thing.  I don't want to get on anyone's bad side, clearly there are lots of benign situations that demand super security and privacy.  I am interested in going through the theoretical exercise to see if I can devise a hack-proof system.  My main assumption is that my computers would be physically secured.

Electricity doesn't work the way you think it does. The direction of current flow has absolutely nothing to do with whether you're transmitting or receiving a signal. You seem to think that signals are transmitted by "pushing" electrons down a wire, where they are somehow "collected" by the receiver.

Your right Foxpup, there is no pushing signals down a wire when it comes to electricity, but I think this would be the case with fiber optics and light.

I was trying to design a crypto communications system where the private key would reside on a computer behind a data diode or two.  You would read the emails, chat, voice or video on that computers monitor.  All of your outgoing communications would be sent from a another computer, which of course would not have the private key on it.  The main stumbling block I have come to is how to verify that the outgoing packets, leaving the computer you are typing on, have truly been encrypted with the intended public key.  I am trying to anticipate software and hardware backdoors.  It would be really nice to have a way to sniff all outgoing traffic and verify that only properly encrypted packets were leaving the network, but without your friend's private key, you can't do the verification.  More thinking ahead!

[RoadToHell]

Why not disconnect the transmit wires at the switch/router end?  If the attacker has access to the switch as well as the computer network card then your whole strategy is of no use since they could just replace the entire cable with one of their own.

[Foxpup]

The only such hack is Auto-MDIX (which swaps the transmit and receive pairs if you used a patch cable where a crossover cable was required or vice versa), which won't work if only the receive pairs are connected.

A firmware hack couldn't remap the pins?

You mean, on your own hardware? If you can't trust your own hardware, you can't trust anything. Game over. You lose.

I was trying to design a crypto communications system where the private key would reside on a computer behind a data diode or two.  You would read the emails, chat, voice or video on that computers monitor.  All of your outgoing communications would be sent from a another computer, which of course would not have the private key on it.

You're talking about red/black separation. Ideally, your red box (the one you're accessing sensitive data on and which stores your keys) won't have any kind of network connection at all, instead using sneakernet to transfer encrypted data to and from your black box (which has a network connection, but never touches unencrypted data). It's the only way to be sure.

[Cubic Earth]

A firmware hack couldn't remap the pins?

You mean, on your own hardware? If you can't trust your own hardware, you can't trust anything. Game over. You lose.

Not so fast, bud, you don't have to lose! Compromised hardware, via firmware or bios attacks, or even malicious chip design is soon going to be a reality to contend with.  The digital arms race is just gearing up - especially as the recent surveillance disclosures have revealed - and bitcoin is in the heat of the battle.  As was said during the conference in San Jose, the state of our computer security systems, generally speaking, are barely ready to handle something as potent as bitcoin.  I know your right, that traditionally hardware has been assumed to be safe, and that that concept forms a basic tenet of security thinking.  Foreseeing the coming onslaught of compromised hardware though, I am trying to think of vulnerabilities and their solutions.

Having different pieces of hardware doing the same job in the security system, and then comparing the results with a third system, or having two or three different models of data diodes in a row are a few examples of how to protect against hardware attack.  It wouldn't matter if one element was compromised in such situations.

If bitcoin gets big, the security systems surrounding multi-billion dollar wallets will have to be as robust as the stuff that protects the nuclear launch system (or at least hopefully does).  If one can design a system that mitigates the risk of compromised hardware, that can help to shrink what is currently large attack surface.

I was trying to design a crypto communications system where the private key would reside on a computer behind a data diode or two.  You would read the emails, chat, voice or video on that computers monitor.  All of your outgoing communications would be sent from a another computer, which of course would not have the private key on it.

You're talking about red/black separation. Ideally, your red box (the one you're accessing sensitive data on and which stores your keys) won't have any kind of network connection at all, instead using sneakernet to transfer encrypted data to and from your black box (which has a network connection, but never touches unencrypted data). It's the only way to be sure.
[/quote]

That is what I am talking about. The data diode would serve the same function as sneakernet, although the diode would obviously allow for the real-time and continuous transfer of data to the red system.  As I mentioned, several diodes could be placed in serial to multiply the chances of preserving security.

[maqp]

Lifting up old topic. I've written a set of tools that utilize an external HW TRNG, OTP encryption together with data diodes to provide most secure communications on civilian market. Open design, FOSS software written with easy to understand python. Describing paper available at cs.helsinki.fi/u/oottela/TFC.pdf

[Cubic Earth]

Wow, I'm so glad you brought this thread back.  Looking forward to reading the paper.  Just flipped through it though - separate transmit and receive stations, each with diodes - that is the way to do it.

By the way, I was in Helsinki in October.  It's an amazing place.

[maqp]

Wow, I'm so glad you brought this thread back.  Looking forward to reading the paper.  Just flipped through it though - separate transmit and receive stations, each with diodes - that is the way to do it.

By the way, I was in Helsinki in October.  It's an amazing place.

main stumbling block I have come to is how to verify that the outgoing packets, leaving the computer you are typing on, have truly been encrypted with the intended public key.

You're right, without the private key you really can't. TFC's OTP encryption can be manually verified using ASCII conversion table (DEC values) and simple clock arithmetics and it's more secure than public key crypto. There are various downsides in convenience regarding OTP but easier auditability and not having to worry about algorithm security makes up a lot of it.

Hashes are used to verify no data errors were present during data diode transmission. From Pidgin you can check what type of message was sent to friend, but in theory a backdoor in both systems could of course send other type of data through serial and into network.

Quoting wikipedia:
Realtime spectrum analyzers are able to see signals hidden behind other signals. This is possible because no information is missed and the display to the user is the output of FFT calculations.

Moreover, you can use a Logic analyzer to store and view raw digital signals.

I'm really glad another person came up with almost the exact same implementation to improve security.

[Cubic Earth]

maqp - I finally read through the whole paper.  Nice work!  The one-time-pad is the way to go.  For high security applications I would definitely add two redundant sniffers onto my transmit line to make sure only properly encrypted packets were being broadcast.  The sniffers would have copies of the OTP to let them do the proper checks on the data.  The sniffers could have a buzzer or flashing lights or something, or even better an auto-disconnect, if they discovered any thing wrong in the outgoing packets.

This system could be applied to voice as well.  To stop any kind of timing analysis the outgoing data stream itself would have to be at a constant bitrate.  That would obviously limit what kinds of compression could be applied, and you would have to use a bigger one-time-pad.  I can't wait for the OTP to come back into style.  Or maybe just into style for the first time?  I am seeing myself always traveling with dvds or even blu-ray discs full to the brim of truly random bits, each one representing 5GB or 30GB worth of secure communication.  They will be numbered, and I will have a copy of each at home.  When my friends and I have run out of bits to pad our communications with, it will be time for another trip to meet in person.

[maqp]

maqp - I finally read through the whole paper.  Nice work!  The one-time-pad is the way to go.  For high security applications I would definitely add two redundant sniffers onto my transmit line to make sure only properly encrypted packets were being broadcast.  The sniffers would have copies of the OTP to let them do the proper checks on the data.  The sniffers could have a buzzer or flashing lights or something, or even better an auto-disconnect, if they discovered any thing wrong in the outgoing packets.

This system could be applied to voice as well.  To stop any kind of timing analysis the outgoing data stream itself would have to be at a constant bitrate.  That would obviously limit what kinds of compression could be applied, and you would have to use a bigger one-time-pad.  I can't wait for the OTP to come back into style.  Or maybe just into style for the first time?  I am seeing myself always traveling with dvds or even blu-ray discs full to the brim of truly random bits, each one representing 5GB or 30GB worth of secure communication.  They will be numbered, and I will have a copy of each at home.  When my friends and I have run out of bits to pad our communications with, it will be time for another trip to meet in person.

Thanks. I hope the paper was easy to digest. The bad news is the entire system has been updated and thus the paper is partly deprecated. New paper is available at the same address.  Reddit has some discussion about the implementation: http://www.reddit.com/r/crypto/comments/23xee6/tinfoil_chat_043_pidgin_im_otp_endpoint_security/

I like the idea of a sniffer to verify traffic and hope you come up with implementation for it. A faster diode is required for VoIP; I'm afraid I've had no success implementing faster data rates, even with 1Mbps optocouplers.

[Cubic Earth]

A faster diode is required for VoIP; I'm afraid I've had no success implementing faster data rates, even with 1Mbps optocouplers.

You should be able to parallelize the diode, setting up a inverse multiplexer arrangement.  One chunk of data gets sent through diode A, with the next chunk getting router through diode B.  It seems like that would be pretty simple to implement.

What has been the problem with the faster data rates?  Do you know where the stream is breaking?  I am assuming you are getting bursts of faster throughput, but it is unreliable?  It wouldn't be easy to negotiate speeds when the machines can't.... negotiate.

[Bitcoin Magazine]

the more $$ you put into security, the more i want to hack your network.  thanks for giving your BTCitcoins importance.

[sana8410]

What about using them for network monitoring to protect SPAN ports, etc? Has anyone even heard such a thing? It was proposed as a solution at a recent industry conference.

[DjPxH]

Wouldn't there be quite a lot of data throughput? Isn't there a lot of traffic on Twisted Pair / RJ45 cables that adding a diode does actually show you 'real' traffic?