Topic: Data diode for high security (Read 7765 times)

Hi members,
 I am new to the forum and searching for the same topic.
 I want to make a Ethernet-based Data Diode.
 Please share with me "how to make" if anybody got success :-)
 Tell me the procedure by providing your guidance.
 Thanks a lot in advanced..

Related more to the actual topic, if you want plug and play removal of Rx or Tx, you can use this : https://greatscottgadgets.com/throwingstar/

Just remember this provides very little protection against covert channels and unintended transmissions. You kind of want the optical gap between the systems.

Edit // off-topic. TFC project discussed earlier in this topic is for the most part finished, and ready for use: https://github.com/maqp

That's a very interesting idea! But I also wonder whether the signal wouldn't be too corrupted maybe. I guess ethernet compensates for that, but will it be enough? Also, isn't there other (management) traffic on those cables, other than actual TCP/IP communication?

What OS did you use on the PI? Did you use SMTP as your transfer method, i' m very interested in this set-up!

Many thanks

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?

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.

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

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.

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.

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.

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.

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.

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

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.

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.

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

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.

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.

A firmware hack couldn't remap the pins?

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.


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!

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.

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

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.

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