Poisoning the Kademlia routing layer seems like something an attacker with modest resources can do. Here is the paper:
This attack is based on three premises:
1.-Kad does not have ID authentication and allows nodes to pick their own IDs.
2.-Kad node IDs are not specific to a node’s network location; a node that changes its IP address will retain its ID and update its address with HELLO_REQ messages.
3.-when receiving such a HELLO_REQ, A does not verify whether B is still running at the current IP address and port.
and these three premises are not present in the Safe network
1.- A node cannot choose its ID
2.- A node cannot choose its network location
3.- Crust verify the current IP address and port
So this attack is unfeasible on the SAFE network.
isn’t the 2. derived from 1. in SN (and Kademlia)? 3. so you can not change your IP in Crust, or does it just verify the correct signature, not the IP?
atm just the signature, but it should also for security ensure that all messages are from the same IP.
hmm, isn’t it going to hurt vaults connected to the internet through DSL or ISPs forcing you to reconnect every 24h or so.
It mights if the whole IP gets changed and not just the port. It is not final yet as crust security needs to take care of that. Basing on key alone can be an issue with folk selling identities, but it may not be an issue.
I should also say though, enclaves can help as well. We have not even gone near those yet, but they can help.
Wouldn’t that be inconvenient for vaults with dynamic IP addresses? Also, that IP addresses don’t often change from one minute to another is more of a side effect of how things are done usually and not by something fundamental to the protocol.
If one is behind their telco’s NAT it may happen that connections go through different routers due to load balancing. I share stuff from my home computer with just one or two friends and when I look at the web server logs I often see requests from the same person through different IP addresses within short periods of time.
Absolutely, but the balance is this
- A vault can have dynamic IP allocation
- A user could “sell” his/her private key to an attacker
So we need to make sure 2. is not possible, but also cater for 1. This is an area we do need to be more clear on, gsx etc. all helps (prevent folk access to their private vault key (users should never need to access this)). There are a few other ideas, such as allow address renewals, but only from same IP network which is sub-optimal and so on. It is an area to clean up though, as I say. Any ideas would be good. It is an interesting thing to “fix”.
I have to disagree. Users who don’t need it would not look for it to start with (so, the protection wouldn’t be necessary) but those who want to use it for bad things can just compile a vault without the protection in place (so, the protection would be useless). The curse of open source!
I agree with your point, if a vault can run without an enclave. If such a system were in place to prevent this then it has a few issues such as how to ensure code is running from an enclave. Some projects are looking at some things along those lines afaik. Although I am not certain that issue is solved.
There are another couple of things to consider (cross platform etc.) but you raise an interesting point?
Say SAFE is out, successful and secured. There are bad actors but not enough. So they want to buy peoples ID (private vault key) to control a section, say. To do that the people they buy from would need to run code that allows them to get the key (imagine it is hard to read a key with the official codebase). So an attacker creates a patch to allow the official code to be insecure against getting the private key.
So you feel people will trust an attacker / bad actor and run their code/patch? Or that people (in enough numbers) will compile their own vaults with weaknesses like this with the intention of selling keys?
I am not sure that people would do this in enough numbers actually and if they were prepared to do that then it would be more folk wishing harm on the network that helping it. So the attackers/bad actors would become a majority, then nothing can prevent takeover (I think).
This may be a tangent to the thread though?
To quote myself:
This is a bit off topic here however. In the quote above I was thinking of buying remote access to enough vaults of your section (from which you know the IP’s) instead of buying private vault keys.
Anyway, it would be handy to have, in due time, a clear picture what (damage) someone can do (theoretically) if he controls 1 or a couple of sections and so the data on it. And what all the mitigations are to prevent/detect it. Like are there other sections who can check if there is data changed/added in an invalid way on such a controlled section.
I agree that this particular attack is not possible with SAFE’s implementation of Kademlia. I guess my question was more about Sybil attacks (combined with Eclipse attacks) on the Kademlia routing specifically.
Let’s say I inject my node somewhere in the Kademlia network. Now it’s accepted, and it’s a “sleeper”, doing all the nice things. My goal is to keep injecting nodes nearby so they take over a given section, or simply subvert it to prevent any further progress. Why? Because I want the SAFE network to get a bad reputation, say, and short the safecoin, or whatever.
OK, so if the nodes start out picking the same address, or nearby in hamming distance, then they wind up around the same place in Kademlia? Can they then poison the Kademlia layer, foiling attempts to route to something, or routing to the wrong node, and so on?
Can I spin up an large number of nodes on one machine, in order to do a sybil attack? Does SAFE allow unlimited amounts of nodes from a single machine or IP range or whatever?
How would you “inject nodes nearby”
With the increase of 4G/5G wifi hotspots (small unit for personal use) being used in the homes/boats/whatever by people (used on in Japan a year ago) there will be a reasonable number of people on high performance internet whose IP addresses can change often in a day.
So with opensourced code its not hard to extract these things or do you have some way to stop access. The Node needs it so how to allow the node to use the key but not allow a modified node to reveal it.
I agree, but if we used say enclaves and the keys stored there and folk could not access them without going through hoops then I think it can be successful.
I think of that “protection” akin to … say lets take bitcoin. There have been times when certain pools got to almost 51% - so attack mode. However, people could have recompiled their bitcoin code to refuse blocks from that pool, to protect btc, but they did not do that. I am not sure open source totally means folk will create their own binaries, in any numbers that would affect us. It may though, but I am just not convinced it would.
tl;dr protecting keys is not simple especially when the owner wants to get it
I’m not so familiar with enclaves etc, so to be sure: I assume you mean sgx (Software Guard Extensions) instead of gsx here?
Ah yes, sorry for the misdirection there
It is probably better referred to as Trusted execution environment. SGX is the Intel implementation, but ARM has something similar called TrustZone.
I didn’t think the sgx trusted zones could be trusted anymore? Or ever?