Attack Vector against relay nodes from client machines run by Investigators

Cybersecurity
1

Background

In Australia and Germany there are cases where a person has been convicted for aiding the criminal/copyright infringment by acting as a relay of encrypted information that the person could not know anything about.

Plus Australian copyright law is clear on a person passing infringing copies on is (criminally) liable

[EDIT: I unfortunately made a mistake on the TOR link. I had followed an Australian news article which gave that techdirt link and claimed it was an Australian case. And explained it as happening in Sydney. Well shame on me for only skim reading the actual case. There is still recent legal precedent in Australia for the copyright trolls ]

One was acting as a TOR exit node and convicted for aiding the criminal with data transfer (data was encrypted and the person with the exit node knew nothing of the data.

The other was another friend to friend encrypted file storing system (a bit like SAFE on the surface) and the person friended a media private investigator. He was convicted because he (relayed) sent the file to the PI. It did not matter that it was encrypted or that he was only a relay passing on the file.

SAFE operation that is of concern

The client requests a file and the chunks are retrieved from the various vaults. Each chunk is passed through many nodes till they reach the client.

The client “sees” a number of relay nodes which are the final nodes for the chunks in the file. @dirvine indicated that it will be 3 or more when live.

eg send chunk from vault to client and client is run by investigator.
vault1 → node 2222 → node 3333 → … → node 1118 → relay node (7555) → client
vault2 → node 1234 → node 9876 → … → node 1111 → relay node (3444) → client.
etc
Now if the chunk was part of a public infringing file, then the investigator knows the ip of the relay node (3444), relay node (7555) etc through packet sniffing.

The client machine monitors the packets and obtain the IP addresses of the relay nodes that finally passed the chunks to the client. .

Question

If an infringing copy of a movie is uploaded as public data AND If the Movie Company’s Private Investigator decides to “go after” suppliers of the film in question. What is to stop him from sniffing the IP addresses of the relay nodes that finally passed on the chunks to the client. Then start proceedings using those IP addresses to get details of the people running those nodes.

As said above it has already been tried in court that even passing on (part of) encrypted files without knowing anything about them is enough for a conviction in favour of the movie company.

Is there some way to protect against that?

Supply fake return addresses in the header of the packets for the chunks?
Some form of peerGuardian, PeerBlock?
Australian and German users have to use VPNs?

1 Like
2

If the client is run by the investigator we are in the “Entrapement” or “Agent Provocateur” and is forbidden by laws in many countries or, at least, discouraged and it’s a possible defense against criminal liability.

3

But this is not illegal in Australia. And not illegal for USA investigators to catch for instance UK people.

They did not upload the file, they just requested it and saw who gave it to them. No incitement, incentive, payment or coercion

Being a civil case does entrapment apply even in USA?

PS. Even if it is illegal in USA, it is still an issue for many countries including Germany, Australia, etc. Then issue for international investigators. Considering they got a conviction in Germany - look at the link

4

I’m reading this thread.

One thing it seems to me like is that relay nodes are used only for requests. Then I thought about this:

Now, the question becomes: is this handled on an individual basis, or do the NAE/Client managers become the endpoints with the relay nodes fixed? Almost like the managers function as a router (WAN) and the relay-client pair are on the private (LAN) side of things. That’s one thing that’s never been clear to me - if that happens for just requests, or both requests and receptions.

5

This is a clear case of incitement. If the investigator node don’t ask for a particular file the relay node don’t have it.

6

With all due respect, (and for you @digipl, that’s a lot of respect) it’s better to cultivate technological impossibilities than to attempt to argue innocence. As I’m sure we both know, that’s becoming less and less feasible in the current state of the world.

4 Likes
7

I think you may be asking a wrong question.

The question isn’t “can you protect yourself from being ID-ed by your closest neighbor”, but “do you mind to transfer such content yourself”.

Technically it’s the same thing, but in the first case you’re the usual guy downloading some TV series, while in the second case you’re serving (in case of a farmer, “storing and serving”) content that may be illegal.

While you won’t download weapon designs and kiddie pr0n yourself, you may serve it. So the second scenario is much worse than the first (should there be a way to ID you).

I find it curious that I mentioned this second risk in other topics, most people dismissed it, but the interest in the first (far less significant) risk is still high.

Who’re are they going to come after first?

@digipl, entrapment is used without any problem. They just tend to use other methods first (aka “entrapment is discouraged”), but if there’s no other way, then they entrap you.

Also they don’t have to do it that way. They can use a version of the Dropbox approach (upload the blocks themselves, and then compare with whatever blocks they see on the network).

One way to get around this would be to use private networks, but then the issue of trust becomes important.
Another way is to change content by random insertion of data, which would increase the cost of sharing unless done on the fly (say, via a Tor Web gateway to SAFE).

8

But it seems from your links that is for criminal cases. Does it apply for civil cases in the USA??

The case in Germany clearly shows that a system that relays encrypted blocks to others at the request of an investigator is allowed and a conviction is possible. Australia doesn’t have those road blocks for civil cases (and I gather most countries for civil cases).

Agreed especially that didn’t rules apply for criminal and civil case and internationally obtained information. Not to mention different rules in different countries.

As you say this discussion is really about the technical solution to a problem for some countries, even if its not the USA which has some of its protections in the constitution.

9

No its a technical question, we don’t want another thread where the FUD about illegal content overwhelms the real question.

I think that legal liability is a different thing to a desire not to “serve” illegal data. Go to the thread that answers that again and again and again! When data is anonymous and unknown is different to knowingly storing the illegal data and serving it. Would postmen, or ISP, or delivery companies be happy if they know they are delivering something illegal.

Please lets not go down the “do we want to pass on possible illegal” material as that is a completely different question to this thread’s topic.

1 Like
10

Yes, if you can consume data on SAFE without at the same time serving it to other nodes on the network.
Is that how SAFE works - you can set your client not to share data to other nodes on the network? I wasn’t aware of that feature.

11

Maybe in your country. In mine, for now, the supreme court jurisprudence does not allow accept evidence taken by police provocation. Even in the case of undercover police infiltrated in terrorism or drugs, the existence of prior offenses is needed to accept evidences.

This two phrase summarizes the current jurisprudence:

The police mission is to discover the crime already committed but not facilitate the commission of another

and secondly (hard to translate)

There is no requirement for criminal responsibility to the subject because the subject had not acted in the same way it did if it had not been caused by the needed infiltrated agent.

12

Wait until there’s a terrorist suspect and then we’ll see how quickly exceptions are made.

Ross Ulbricht’s systems were broken into without a warrant. Soon in movie theaters around the EU.

2 Likes
13

Just a short question to @neo the original poster: You are often referring to Australia, while the second article you linked seems to be about Austria… which one do you mean? (no kangaroos in Austria!!!)

(Austria is a neighbour of Germany, the birth country of Adolf Hitler, and they speak German with a silly accent)

1 Like
14

But there shouldn’t be any association with IP in SAFE as the routing layer uses the network specific IDs for communicating. The only reason the Tor node was found was because it was an exit node which links back into IP.

2 Likes
15

What could happen in the worse case is that you connect to say 8 nodes on IP-level. Just like with the full Bitcoin-client. Than some government agency requests an illegal file on the network. The chunks come over these 8 IP-nodes even while these nodes never had a clue what they were forwarding. The Chunks are fully encrypted but the connection also is! So the node even didn’t know what Chunks they delivered. That government agency could now accuse you for delivering parts of an illegal file. But when you reset your computer on a daily basis there’s nothing left for them to use as evidence. And as far as I know these sort of things never happened with Freenet. Even while they’re around for over 10 years.

1 Like
16

Vault ↔ End-client - that is correct, IP should not be known
End-Client ↔ Relay node - that is incorrect, IP must be known
End-client ↔ NAE/Client manager - that is correct, IP is not known

If the chunk being returned goes back through the relay node (via a NAE manager) then there is nothing I can say @neo. However, if it does not, it is possible for udp packets to use IP spoofing - since there’s no agknowledgement packets being sent to the sender. It’s supposedly non-trivial, but possible.

That way, on the return path, wherever you ultimately recieve the data from, you wouldn’t know their real IP address. Whereas if the data always flowed through the relay nodes, you’d know exactly who they were.

4 Likes
17

I don’t think this is necessarily true everywhere.
In practice only your telco’s (or “investigating organization’s”) logs could be enough. Your interpretation of what might constitute evidence seems a bit too casual (see example below).

The judge authorised handover of IP records for three purposes:

  1. seeking to identify end-users using BitTorrent to download the movie
  2. suing end-users for infringement
  3. negotiating with end-users regarding their liability for infringement.

(source - http://www.lifehacker.com.au/2015/04/what-evidence-does-using-bittorrent-leave-behind/)

18

That’s apples and pears. In Bittorrent you share chunks with other who download the same file. So you have to be downloading/uploading the file and know that you’re doing that. Another point to make is that on Bittorrent the chunks aren’t encrypted. So you just pass around un-encrypted chunks from a file you are downloading/uploading as well.

19

There is a protection for this, now I have had a wee while to think about it (nice investigating @neo), the routing layer will know when delivering to a bootstrap/relay node. It can tell this from the address of the client which contains (NodeAddress, Client_public_key) so the node that is connected to the relay node will know it is delivering to the last hop. In seeing this then the routing node can encrypt the whole message to the client, this essentially means the relay node (bootstrap node) cannot tell what the client is receiving and the relay is then protected.

This is pretty easy to achieve and we can give this more thought. The reason not to end to end encrypt the whole message is to allow caching. So this is for ImmutableData only, all the other data types are encrypted end to end anyway, making this attack not possible there.

6 Likes
20

With SAFE you also know you’re downloading the file (I thought also uploading if you’re caching it).

Below your comment David said they currently aren’t.