FAO Network admins/techs... question..

OK, lets assume that you have 3 nodes in your network, all participating in data transfer.

Node A is sending information which Node C has requested. Node B is acting as a bridge. If you disconnect (physically) Node B, there are other nodes in the network that will take up the job of acting as a router. These 'spare bridges' are scattered randomly around your network, and you won't be able to find them until they start actively transmitting/receiving.

You suspect that the data transfer is illegal, but suspicion is not enough grounds to disconnect either A or B from the network. The data transmitted is encrypted to a level that it would be unfeasable to decrypt it.

Since these nodes are also being used for legitimate purposes, node's being down, or even the entire network being down cannot be done.

Where would you start to resolve this situation?

EDIT: If your initial tactic is to use the same software as the nodes are, and try performing the same search that Node C did (ala RIAA's methods). That's fine, but all data would appear (from your machine) to be coming from Node B, not the actual source of Node A.

NB, I'm designing a system that should in theory be impossible to take down... this system will be used to transmit legitimate information, but I'm also concerned of it's potential for abuse, hence the post...

[MiniMac]

Not sure of the answer, but I'm interested, so *tag*

Look on the logs of B

Originally Posted by MiniMac

Look on the logs of B

That's interesting that is...

Now, supposing as a System Administrator you had physical access to Node B, you could in effect put software on it to reveal the IP of both A and C. This will also mean however, that all 3 nodes must be in your network. Anything outside your network, would make life more difficult.

The data transmission software will log, but it will consist of the following format (saved in plain text on the node):
<Node B ID>;NC;<Node A ID>
<Node A ID>;NA;<Node B ID>

Meaning "I have attempted connection to Node A, and Node A has accepted a connection from me." The ID's are randomly generated at run time, and are 64 character alpha-numeric strings. Every time the application launches, it has a new unique ID (64^62 combinations - and any ID clashes are catered for).

[SoulKiss]

Well I put this to a couple of mates of mine and got the following

Originally Posted by RBW

Since you say it's my network, I'll just replace node C with a hot spareand put it under the forensics probes.
Failing that, traffic analysis. Measure transfer volumes and timings.

Specifically in this case I'd run tcpdump with filters, or ntop, on node B, to verify the data path, then ask A's owner to account for it.

And from another

Originally Posted by I

OK, let us assume I have administartive control over either B or (at least)
all network paths to B. I suspect taht this might be going on. If B goes down,
it'll just re-route, we don't want that because we're wanting to intercept the
traffic.

So, the data stream is encrypted, however, there needs to be a key exchange in
there.

First point of order, what key exchange mechanism is being used? Maybe we can
find a way of recovering the session key?

Second point of order, traffic analysis (as RBW mentioned). This can point
us to both A and C (and, indeed, we can probably recover that WAY easy if
we're in control of B).

Third point, this time of disorder. If all we want to do is make the
transmitted file useless, we can (probably, depending on the architecture of
B), do on-the-fly deep packet rewrites, subtly changing the data (if we
randomly bash some random bytes in every tenth packet, we'll get corrupt data
through in roughly 1/65536th of all bashed packets; expecting full-size
packets, that's one successfully perverted file in every 960 MB transmitted).
If we're TRULY evil, we can do better, but that would entail actually changing
16 bits, so that the CRC doesn't change. We can up the bashing-frequency, to
affect more shipped data.

Fourth point of order, what Ts & Cs are A, B and C operating under? In a
suitable environment, I can just order a complete audit of A, B and/or C, on
suspicion of bad behaviour. I may even be able to quote bandwidth usage as a
reason. But, this depends.

What are you actually wanting to check? Feasibility study of "is legal, not
pervertable"? Feasibility study of "subvert and/or take over"?

Thanks SoulKiss, I was kind of hoping you'd ask friends, as your friends are exactly the type of people I want to hear from...

Right, key sharing...

Each node generates it's own random key for each of a potential cryptography alg (and I'm talking AES196, Blowfish and RSA-2048 minimum here). RSA key will obviously be 2048bits, AES196 will be 16bytes, as will blowfish.

The problem becomes, swapping keys. For this, each node contacts a HTTP site to ask for the current temporary key. Keys to be swapped are then encrypted (progressively, using all availabe shared algs) and exchanged.

EDIT: I forgot to mention as well, that keys for AES196 & Blowfish change on every packet transmission, based on the plaintext contained within the last packet sent.

If you elect to take out the connection to HTTP (as this is the easy target), each node defaults to Fail Safe mode. In this mode, an incoming connection will be met with a 128byte random string (including symbols), then the connection will be dropped. If the node connecting fails to re-open the connection and transmit encrypted data (using the random data supplied as a key), the node is immediately ignored for a defined length of time. No second chances.

Filtering/tcpdump, if you own the paths to a given node, would reveal the encrypted payload, which is useless to you. It would also reveal the destination/source of that packet. To counter this (as we don't want people sniffing traffic anyway due to sensitivity of legitimate data transmitted), I'm planning a TTL, whereby the encrypted data will not be sent to Node C until it has been passed through an arbitary number of hops (I simplified the OP on purpose compared to what will actually happen). So you will know the IP of the machine your node is connecting to, but you won't know if this is either the source, the intended destination, or even just another bridge.

Being evil, and altering packets would work to corrupt them, but do bare in mind that there is likely to be more than one source (yes, this is a P2P/P4P network) sending data through ideally many many bridges. Your data corruption would slow the transfer down, but as a result, your node would suffer the consequences.

EDIT: The transmissions between nodes may be multiple different files, some of which are legitimate, others may not be. Altering every nth packet may also corrupt legitimate data transmissions.

Remember, these nodes are supposed to be transmitting legitimate (wanted) data between each other, and acting negatively on any node isn't really desired. Although I acknowledge that if you suspect the machines are being used to transmit data illegal, you may want to act somehow. It's a matter of risk analysis here.

Asking Node A's owner to account for bandwidth is pretty useless, as the application may be doing this in a fully automated manner. It's being designed for "groups" of nodes, whereby each node may automatically send anything that's on another node's "subscription list." The owner of any given node may not be fully aware of what that node is transmitting.

As for T&C's, that's down to the owner of each node/network to establish. But the application is being designed to allow limitation of bandwidth to prevent "fair usage" breaches etc.

As for what I'm wanting to establish... well, I'm trying to design a system that is inherrantly stable (automatic load balancing etc - hence nodes restructing the network if a given node falls over), and transfers content that is required. What I don't want, is legitimate users of the system, hiding illigitimate content & sharing possibly illegal files. I'm not planning on stopping them from doing so at the GUI level as this is practically impossible whilst allowing users to use the system. I'm more interested in the "if someone did something naughty, where would be good to start looking?"

I could add in features to reveal node IPs etc etc, but that is specifically not wanted by the client as it's deemed a security risk.

[SoulKiss]

Another reply for you

Originally Posted by RBW

Easy!

Don't block the HTTP stream, intercept and modify it at the network
border. You have no primary authenticator.

SoulKiss, if you modify the key sent via HTTP, then you have a couple of options:

1) The temporary keys on 2 nodes will not match, and both nodes will default back to Fail Safe as detailled in the above post.
2) If the temporary keys on both nodes do match, they'll perform key sharing as per the above post.

Either the HTTP service provides the same key to any 2 nodes in the network (in which case unique key sharing is possible), or it doesn't (in which case you revert the nodes to Fail Safe).

If you know the temporary key, you still have to know how the application encrypts the other keys based upon that temporary key. No sensative information is transmitted unless it's excrypted by the node's own generated keys.

Once key sharing has occured, knowing the temporary key provided by the HTTP service will get nothing.