The purpose of this thread is to discuss and collate security issues with no concrete plan for resolution. Kind of like a github in this great forum.
I feel we should discuss any percieved security risks, their severity and propsed mitigations. Please tile your percieved security risk. In addition provide a PSI# (perceived security issue number) in numerical sequence relative to the previous post.
Please follow the format below for easy readability and item discovery.
Relay Chunk Fingerprinting Attack
PSI#001
STATUS:
Open
DIFFICULTY:
Moderate
CONSEQUENCE:
Uploaded files can be tied back to the content provider. Liability issues may arise.
METHOD:
A resourceful attacker collects offending files/data (music, movie, games etc) from various sources online then generates a growing database.
The attacker, acting as a relay node, monitors chunks uploaded by clients connected to it.
Using a clients Public Key, an attacker could use the very same convergent encryption method used by maidsafe.
The attacker uses the target clients Public key to self encrypt the files in the database of offending data. If any of the resulting chunks match the chunks that passed through the attackers machine while acting as a relay, the uploader can then be held liable.
PROPOSED SOLUTION:
Onion encryption/tunneling.
After the initial self encryption is completed, a node other than the relay (lets call it node 3 ) provides the client with its Public key via an encrypted message. The client then further encrypts each chunk with node 3s’ PK. The upload commences and the malicious relay is left with nothing useful.
FEEDBACK?
Please respond by first including the the PSI# in bold characters. Linked replies on discourse usually only have a picture/icon associated and require a click to expaned the post that is being responded to. It’s IMO tedious and not as easy for browsing.
Been told these will not exist in the later versions.
I thought this is what is going to happen. The chunk being uploaded is encrypted. Not sure why the client’s public/private key would be used for that encryption.
A while ago this was a node that acted as the node a client talked to and it relayed the messages to the first section.
In alpha 2 IIRC the client connected to one relay node only and the idea was that there would be multiple. But more recently it has been said that there will not be relay nodes.
But that was before so much work has been done and it would be good to have some confirmation by a team member or someone who knows the current mechanism.
No more proxy nodes after alpha 2 They were used to rate limit and more, but because we owned them. It would not be possible to do that in the real network.
No we have this
clients ----connect to -----> Vaults (the Elders of the section this identity (pub key) belongs to)
With vault phase I we will have
clients —connect to ----> A single vault representing the whole network [this allows us to test the client and vault code without routing)
Then we have
cients —connect to ------> A single network (no sections) and this allows us to also test much of routing.
Then Fleming which is a network of many sections.
I was explaining this recently. Just think clients speak to vaults, they don’t care if it is a single vault or many of them. So a client → vault relationship is enough for client.
Vaults on the other hand do care as a single vault does not scale, so we add in routing. However we only add routing to vaults, no need to confuse clients with all that complexity. So easy way to think is routing decentralises the vault and it simplifies the picture. It also means we can much easier test locally with just a single vault and many clients. So not mock routing any more just local network.
This buys us much more speed to launch and also buys devs a much better local test network
In terms of personas, the vaults’ persona a client will connect to is still the “ClientManager” persona, correct? (I am asking about the situation at launch of the real safenet, not intermediate alphas, betas etc.)
Yes well the client manager is only the src Elders now. So the Elders closest to the client identity. For now we have shrunk all personas to Elder Adult Infant, Elders do most of the admin, Adults most of the heavy lifting managed by Elders and Infants, well not much at all right now.
So let me get this right. The client connects to its close elder (singular or plural?), then the close elder forwards (relays) the client’s traffic its destinations. From my understanding the close elder provides the public key for encryption. If so, what prevents the close elder from carrying out the above fingerprint attack?
The client signs with it’s key any request. The Elders then agree this is valid and sign as a group (via PARSEC/BLS). The client connects direct via TLS 1.3 to those Elders (not forwarded).
Clients do not use their public key to encrypt etc.
I am not sure what the “fingerprint attack” is referring to. But in any case here is some info.
The Elders scrub the IP etc. so beyond that we don’t know the client endpoint.
If there is a malicious Elder they will see what the client is uploading/downloading (at the moment anyway).
Attacker gets their Node to Elder status and then checks all chunks looking for or recording the hash of the chunk to know who is uploading what for those connecting to the elder.
The elder is looking for specific chunks that they determined from self encrypting the files they are looking for
Several, first though frame the attack, it is only previously known data, so more a rainbow type attack.
Much of these kinds of things can be placated (and I won’t spend time here as I am forcing a big push to full working network to let folk see the whole thing) by allowing relay through anonymous id’s. So a Client encrypts a request to remote section using the sections key to encrypt the request which is relayed back to the client who can decrypt the response (that is encrypted via it’s anon id).
There are many ways to do it IMO, but right now I am looking to get the simplest possible release and honestly don’t wish to take Engineers minds into these areas until we have the whole network.
For instance personas have been simplified, connections simplified and so on to get us to feature complete. Otherwise we get folk in a silo thinking of only one solution based on the lib they are working on. When the whole network is in place then it is really easy to seal up the edges. It’s a tough one as I am almost forecful in keeping folk on getting all the basics in place.
There are a few small/edge case things like this we could list, but my fear is “sorting” these before the network exists. After it exists these are much simpler to explain (and code).
For sure that is a valid approach. Prob the simplest (so likely best). But I think there are a couple of things related to this that can all be covered with very slight changes to the client connect model
which is a network of many sections.