A successful attack on Freenet

Interesting article, I think that dark webs actually make it easier for people to get caught when they’re consistently doing things that shouldn’t be done, since the cops can deal with the criminal activity directly and with the cloak of digital identity. So I think encrypted networks keep the good people safe as they should be, and give the criminals a false sense of security (not talking about the network), eventually justice finds its way through to the criminals and they get caught. I recall reading that criminals don’t get caught because the technology failed, but because of external factors (in the freenet case it seems to have been the technology that exposed the people along with their illegal activity) if they we on freenet not doing illegal things they’d not have been found.

2 Likes

It seems to me from TFA they mention at least one guy (of course a policeman) who got busted for accessing illegal porn using Freenet.

Note that they used the same approach which may prove dangerous to perverts (and dissidents like) who will use SAFE Network.

(The cops’) computers kept logs of certain Freenet users’ IP addresses and the codes for what they were downloading, according to the affidavit. Agents then compared the codes with a database they built of codes known to be child porn.

This was discussed recently and the approach is a mix of Freenet and Dropbox approach. The first part is if you (the pervert) download from the cops’ SAFE nodes, they know what you’re downloading if the data is public. Or maybe you’re just a dissident whose computer is infested with malware implanted by the government. In any case, you download illegal porn and they bust you.
The Dropbox part (knowing hashes of “incriminating chunks”) is possible if the share is public.

It may be wise to access illegal stuff through a Tor-based Web gateway to Safenet.

A client doesn’t make a direct connection with the vaults holding the data though, it’s routed through the DHT, so chunks are bounced over the planet many times before they arrive. It wouldn’t be easy to figure out who’s downloading a particular chunk from the perspective of a vault holding said chunk.

In that case Tor won’t help either…

5 Likes

With all due respect…what!?

But BCI investigators were able to devise a way to tell which IP address–and consequently, which Freenet user–ultimately was downloading the offending files.

That is called a straight up hack. They are claiming to have hacked the network. As an aside, I would love to hear Freenet’s response to this.

But back to the point. Let’s examine your statement here:

I take only one issue with this statement. The word “you’re”. Who is “you”? (I’ll leave the metaphysical pondering for another time)

First off, the Network does not allow access to anything outside of itself. Which wasn’t really a factor in this case, but it does mean that no data outside of the Network can be used by LE (Law Enforcement).

So the data must be kept inside of the Network. Which, as we all know, isn’t kept in files, but rather in chunks. So taking the hash of the chunk would not positively identify a target file. (in your quote they call the hashes “codes”) As an aside, the hashes of these chunks (of pictures in this case) can be found and tagged by uploading the pictures to the Network and studying the datamap that is rendered.

Now, logs could be kept of what chunks were being retrieved from any vault that LE were running. They could also keep track of the MPID that they were being sent to (NAE Manager). In this instance they can only hope to control a vault which contains one of the chunks with the matching hashes. Likely this would result only if LE was running many vaults (joke’s on them…the more the merrier).

Now they know which NAE Managers are requesting specific chunks. However:

While the NAE Manager may be found out to be downloading specific chunks, the NAE Manager is unable to render up the IP address of the client - or the relay, because:

So the relay node may not know what it’s passing, but it knows what IP address it’s passing to. The NAE Manager is aware of only the MPID of the relay node. (the XOR address using DHT)

What do we have so far? LE knows that a NAE Manager requested a flagged chunk held by an LE controlled vault. They do not know the IP address of the NAE Manager. If they happen to control the NAE Manager as well, they can know the MPID of the relay node, but not it’s IP address. If they control the relay node as well, then we have a Network completely run by LE! All jokes aside, they would then have the IP address of the client. However:

When you can connect to known nodes, this attack is completely mitigated. Done. End of story.

If you route through random relay nodes that are owned by LE to connect to NAE Managers owned by LE and request a chunk tagged by LE from a Vault that is run by LE, it follows that you are participating in a network that is completely operated by LE.

Having your IP discoved when participating in anything less than a network that is completely operated by LE would be an outright hack of the Network.

C’mon @janitor, you’re better than this!


As far as searching a target’s device (targeted using other means than IP address, of which finding out is impossible - or a hack - as explained above):

Police also have the technological tools to quickly scan suspects’ computers while in the field or carrying out a search warrant at a suspect’s home or workplace.

Everything in this statement implies physical access. No malware involved. Although I’m sure some could be devised, but I would assume that it would be incapable of mass infection. Even if it was, it would still have to be cognizant of the client’s XOR address at the time of download to report on a specific client which is randomized every time the client connects. (I visualize something that works like anti-malware does at this time - which is an attack the Network can do nothing about, but interesting nonetheless)


P.S. BTW, a big thank you to @Seneca for starting and all who participated in the thread linked below. Very worth the read.

P.P.S. The linked article in the OP is written to convey FUD bullshit of the worst kind.

7 Likes

Reddit doing what reddit does best:

My theory: they ran enough nodes that over time they were able to pinpoint a node through which requests for child porn frequently came. [There are around 10,000 nodes in and 150TB of data on Freenet] - so taking control of a reasonable chunk of Freenet shouldn’t be too hard for a government organization.

1 Like

What was mentioned as more likely (since you can’t decide that you want to hold a particular chunk) was to be the node that passes the chunk to the actual downloader, because you know his IP address. I can’t find that thread, but here’s a similar (thankfully we have 5 topics on each subject).

What wasn’t sufficiently emphasized is that for public shares, because they’re public, one can know each chunk’s hash.

In case Tor relay nodes are Web servers that act as HTTP proxy to the SAFE network, they’d have to break the both and ID the relay node plus the Tor user. It’d still be possible (to use this approach to ID users of public shares) but harder.

I don’t see what that has to do with DHT. The Last-1 node transfers stuff to teh Last node. There’s an IP connection between the two.

Well it wouldn’t be a hack if they deployed 5000 cheap VPS in a 1000 node network and just waited to see the right chunk passed to the ultimate destination.
That’s how it sounds like. We’ll see if they were stoopid enough to exactly explain what they did.

And how do you connect to known nodes, when you start with a set of MaidSafe seeed nodes which government agencies can spoof? I don’t think this can be so easily dismissed. They somehow did find those guys.

They just need to own one “Last-1” node that passed 1 chunk of 4700 you download in a full length public DVD file, so if you’re spraying your requests all over the network, it seems you’re guaranteed to get one requests routed through a LE system. Maybe I’m wrong, but can someone explain why?

Reddit: so how’s that different from what I said? (On Freenet, you need to add only trusted nodes, so they probably gained trust of some users and then served as a routing node (aka The Last - 1) for them; on SAFE that’d work differently).

There was this thread the other day that discussed a similar scenario, and I have to say I am pretty confused. Like one year ago or so I had the impression that @dirvine said that even chunks belonging to public files are encrypted on the way from the vault to the client in a way that even the last node can not know what it is serving (in an onion kind of way like TOR, in addition to the self-encryption, which does not really matter for public files). Now it seems that chunks belonging to public data are just routed in plain text. Did I misunderstand something a year ago, or has the protocol changed in the meanwhile for performance reasons? Thnaks for clarification!

Files longer than or equal to 3072 bytes are split in chunks that are encrypted and compressed before being put in the network. This process generates a data map which can be inserted in either a public or private directory. So no worry, chunks are always stored encrypted in the vaults.

I understand from that recent thread that I couldn’t find but DrVecctor also mentioned, that data from public shares is encrypted, but of course since it’s published as public, you can say that everyone has access to the key used to encrypt it.

Not at all. I think it’s best to ignore most of what @janitor posts, because it is usually wrong on the technical details, and goes on to make false criticisms of the network.

If @janitor wants to have this or future posts taken seriously, and not just removed, he’s going to have to start backing them up with references to allow them to be checked more quickly, because clearing up the misleading information he’s posting is taking too much time, and he’s devaluing the forum.

5 Likes

Spoof, like in imitating that they are the seed nodes?? No way. PKI is coded in, so when you connect to a seednode from Maidsafe it’s encrypted from byte 1. If someone would “spoof” a node like that they need to have the private key. I wish them all luck brute forcing the PKI.

1 Like

No, not in plain text. It is encrypted using self_encrytion but the hashes to decode the chunks back to the original data are public as well. So everyone who wants to use/see the file can do it. But they still need to decrypt the file.

You won’t be able to sniff the network and say: “Hey, Chunk ABC was just passed to IP 33.55.44.33.22.11” Even if you are the relay-node that passed chunk ABC to the address.

This one needs a little update, but the main assumptions are still correct IMO.

2 Likes

I understand what the self encryption does, and I don’t think that it is really any kind of encryption as long as the datamap is public (because I know that chunk ABC belongs ot illegal file XYZ). But if it is true what @popolrene says, that nodes don’t know what chunk they are relaying (like TOR), then I think there is not much to worry about. To make it clear: I am not at all asking about self-encryption, I am asking about additional encryption that actually prevents relaying nodes from knowing which “self-encrypted chunk” they are actually relaying,

I would trust your recollection of the previous discussion - mine concurs - but if you doubt that it would help clear up the confusion created on this thread if you could dig it out for us. :wink:

You didn’t misunderstand. Here (and check out the two comments before this one):

On this same page this is David’s comment that seems to indicate that this threat potentially can be dealt with (i.e. isn’t dealt with in any way right now, as far as I can tell from the comment).

Reading the later comment (the first URL) I understand that encrypting public file chunks with the last node’s public key isn’t going to be useful when the node before the last knows its content and the last node’s IP address.

Of course they aren’t that stupid. They need to ensure your MaidSafe package contains the “right” keys. While I doubt they’d use that to catch some Piratebay schmucks, more serious users can be targeted this way.

Okay, I look forward to explanations about those public data chunks…

1 Like

@happybeing: thanks @janitor, this was exactly the thread I was having in mind…

1 Like

Well done @janitor, that’s a useful post.

I don’t get what you mean. How can they target more serious users? If you use a public key (hardcoded) to encrypt data and send it to the Maidsafenode, how would they get in between??

If they can interfere with the data coming from a github server or from the maidsafe website (in case the public key is displayed on the maidsafe website) they could do the spoof. Otherwise probably not. But I am still more concerned about the liability of relay nodes to check every chunk they relay for not being illegal. If they have to do this, we can just as well use bittorrent (apart from the incentives that safecoin provides).

1 Like

My guess is an attack on the PC directly and intercepting the private keys, either through physical access or infecting the hardware/OS. But for that, you already have to be a target and there is no real protection against that kind of attack.

1 Like