Analysing the google attack

Community Blog Posts
1

This post follows on from the simulation in Explaining group splits and merges

A ‘google attack’ is when a large company (such as google) owns a significant portion of the vaults on the network. This attack may have a few different effects:

  1. Control of consensus for sections
  2. Network disruption via churn during simultaneous exodus

This post explores the first point, where consensus over sections can be exploited.

The table below shows the results of a simulated google attack on a network of 100K nodes. If the attacker controls more than 62.5% (5/8) of the vaults in a section, the section is considered successfully attacked (see caveats below).

  • before - how many vaults are in the network before the attack
  • after - how many vaults are in the network after the attack
  • sections - the total number of sections in the network after the attack
  • attacked - the number of sections in the network that are controlled by the attacker
  • percent - the percentage of sections controlled by the attacker in the whole network
Before After Sections Attacked Percent
  100K  110K     7120        0    0.00
  100K  120K     7507        1    0.01
  100K  130K     7908        9    0.11
  100K  140K     8316       26    0.31
  100K  150K     8766       80    0.91

  100K  200K    11905     1969   16.54
  100K  300K    17468    11536   66.04
  100K  400K    23809    20920   87.87

Caveats:

This simulation does not consider node ageing, where only the oldest vaults contribute to quorum. On one hand this makes the attack significantly less meaningful, but on the other hand if the vaults are left long enough then statistically it’s almost the same result in the long run.

This does not factor in any cost of the attack, nor any benefit of the attack, which is a crucial factor.

This assumes the attacker is malicious, when most likely an attacker doing the google attack would be benign (eg intern starting a lot of ‘vanilla’ vaults without their boss knowing).

The google attack ignores other large participants. If other large participants simultaneously attempt to perform this kind of attack the proportion of the network under control of any one entity is greatly reduced and the ‘attack’ merely becomes ‘participation’.

This simulation does not differentiate between the various degrees of control of the vault. For example, many vaults may be run by many individuals on Amazon Web Services. This means the degree of collaboration is low so group consensus is not affected, but if the datacenter fails then it may look like the network is experiencing a google attack.

31 Likes
2

Could you outline the consequences of having a compromised section? I think they could make fraudulent coins and deny access to or destroy data. Is that correct?

3 Likes
3

I’m not sure, but here’s my attempt to answer (don’t take any of this too seriously!)

It depends a bit on datachains for data (ie not datachains for network events which is what is currently being worked on).

To the best of my understanding, controlling section consensus currently would mean

  • any immutable data in the section could be deleted (but not modified or created for free)
  • any mutable data in the section could be created (within the bounds of the section prefix) or arbitrarily modified (including safecoins). The ‘bounds of the section prefix’ prevents too much benefit though since the attacker would need to be able to create mutable data that conforms to their section prefix which isn’t necessarily easy.

Having said that, if other sections are able to audit their neighbours (eg using datachains for data) it becomes harder to benefit because an attacker needs to control neighbouring groups as well.

It’s hard to say how much ability there is to kill misbehaving vaults when a section has compromised consensus. It’s sorta the point of the whole network to not need consensus for everything by everyone all the time, so the wider the needed coverage of consensus the less advantage there is to having sections. I’m not that familiar with the way ‘consensus conflict’ scales to multiple sections and haven’t really thought that much about it. Hopefully someone can answer this better than me.

9 Likes
4

Very cool thought experiment. Thanks. Helps visualizing a lot.

If I read your numbers correctly, they indicate that it would take 3x existing network nodes being added by a single centrally-controlled source to achieve the +62.5%. Anything short of that would be, as you say, participation. Multiple, uncoordinated actors would simply make it harder for each other. Very cool.

This also assumes, I think, that there is huge back-channel networking and data exchange between these nodes to allow mutual knowledge and coordination, in real time. Gets mind-boggling pretty quickly.

Adding data chains for data and section cross-checks and it gets pretty tight.

6 Likes
5

This is not quite correct. The table lists the percent of sections in the network that have been compromised. So if the attacker has 3x existing network nodes (ie adding 300K to a network of 100K) the attacker would completely control 66% of the network. Ideally the attacker has control of 0.00% of the network!

The key takeaway from the results is that an attacker owning 10% of all vaults on the network still results in no effect. More than that and they may begin to gain control of a section (at least as simulated, reality may differ due to 1. ageing and 2. quorum being determined by ‘group consensus’ not ‘section consensus’ and 3. datachains for data).

So how many vaults does it take for the google attack to have some effect (no matter how small)? Somewhere between 10% and 20% of all vaults on the network results in a section being owned by the attacker.

This isn’t necessarily a good result or a bad result, but it does put some numbers around the otherwise intangible question of ‘how much is enough’ for this kind of attack.

8 Likes
6

Hmmmm - including node aging and the elder concept, assuming some kind of gaussian distributed reconnection behavior of the good nodes… It would be interesting how long it would take the attacker to get to that point you calculated there :thinking:

(assuming all good nodes being farmers with no reconnect you’d have the high percentage of attacking nodes but 0 effects because they’d ‘never’ become elders… Of course not correct because locally they could control a section after some splits :thinking:)

4 Likes
7

Nice work

Yes even one section is 1 too many.

Was this done with a spreadsheet? and can you make it available?

For me honestly though makes the above simulation interesting and only really useful when there is a simulation with node aging for comparison.

I would be very concerned with this sort of figures.

Now do you consider that a google attack would be using these sort of node numbers of 10K to 300K? Or in a realistic situation would they be using much higher numbers?

The reason I ask is because I would consider a network with 100K nodes (before #) to be a baby network starting out. Because if I am not mistaken Maidsafe themselves would have many thousands of nodes at the start and many of us in the forum would likely have quite a number of nodes and 100K might be the starting point of the live network with maybe a few hundred thousand nodes within a week of going live. (educated/experience Guesswork)

7 Likes
8

As a speculation of mine, maybe some big companies like Google and Microsoft are willing to support the SAFE network with a lot of vaults early on in order to secure the network and to use it for their own businesses.

3 Likes
9

I’ll put the code up on Monday. It was done by extending the python code of the previous ‘distribution’ simulation linked in the first post. The network is initialised by adding 100K nodes, then a series of 900K events where a new vault joins and the oldest vault leaves, putting the final network size at 100K. It’s important to simulate merging as well as splitting since they have different effects on vault distribution and section size. After the network is established, attacking vaults are added en mass. At the end of them being added, each section is analysed to see if the attacker controls >5/8 of all vaults in the section. I call this ‘fake quorum’ and is a heuristic for ‘real quorum’.

‘Real quorum’ means only the 8 oldest vaults are used to form quorum. However, if the attacker controls 5/8 of the entire section, in the long run I consider this to be the same as controlling ‘real quorum’. The exact behaviour of old vaults can be argued many ways, but it can’t be known in advance so I consider ‘fake quorum’ to be the most reasonable way to model control of a section.

I completely agree, but feel the ‘fake quorum’ heuristic is fairly reasonable. Unfortunately modelling vault departure (and thus vault age) is difficult since this comes down to human behaviour. The heuristic used in the model gives an indication of the magnitudes to consider for the attack, not necessarily any precise prediction.

For example, before the simulation I couldn’t answer ‘how many vaults does it take to control a section’. Now I can reasonably confidently say it’s about 20% of the network. If someone spreading fud claims only 1% I’d now have grounds to doubt their claim and request more detail.

In reality these would be much higher since I expect there will be many millions of vaults in the real network.

The exact numbers used is unimportant (since this is a statistical attack it’s only the proportions that matter). 100K is simply ‘enough’ to test with and find the proportions.

So to highlight the proportions that matter: an attack adding 10% more vaults is meaningless. But an attack of adding 20% more vaults may be dangerous (depending on how ageing factors in). An attack which adds 100% more vaults (ie doubles the network size) is very dangerous, leading to approx one in every six sections being owned by the attacker.

I don’t imagine it being feasible for a single entity to add more than 10% to the network, and if they were willing to spend that effort they would gain more utility being altruistic than malicious (cost vs benefit etc), same idea as why 51% mining attack in bitcoin is often seen as pointless.

6 Likes
10

I would think this is the least likely case and to have it as the only case seems to be looking at worse case scenario only. Is that what you were after? EDIT: Oh thats right no aging so it makes no difference does it

Generally I would have thought that the oldest node is the least likely to leave since it is the oldest for the reason that it is a “stayer”. So while it will leave at some stage, it won’t always be the one leaving when a new node is added.

Personally I would have a random choosing of the node that leaves and have a weight so that I could simulate different scenarios of behaviour. Like the oldest IS the most likely to leave or the middle age ones are or the younger ones are. Since there is a randomness then the weight is just an “on average”.

Of course though node aging will make a big difference to the simulation.

@dirvine Maybe something to consider for future. If a section/group has more than one node from the same subnet then only one can ever be promoted to having voting rights. Just an extra protection as even a mass “google attack” would not always see a section/group with more than one from the same subnet but it would happen sometimes and maybe enough that this protection would be helpful.

Unfortunately it is only reasonable if the reality follows the pattern of node departure you implement. As I suggested above using a weighted random selection of the node that leaves would provide a much more usable simulation.

Also what do you think would be the pattern of subnets these “google attack” nodes be coming from? I ask because if node aging included the “only one node from the same subnet in a section/group can be promoted to have voting rights” then this might be useful to simulate in order to get an idea of how useful the feature it would be.

And for that it is very useful and definitely worthwhile. And with node aging I’d say that it will be higher than 20% and if you consider that the oldest node is the oldest because the owner wants it to stay. Also remember that a aged node that leaves will return and will have enough age to have voting rights very quickly as opposed to a new attack node.

Very true. I did consider the attack numbers to be low :wink:

Yes only the largest entities could do such an attack. And hopefully they see greater benefit in helping than attacking.

Of course unlike bitcoin where only few can effectively mine now, SAFE will allow the multitude to farm.

This simulation shows how important it is to get node aging right and not just a simple “how many events it exists for”

It would also be interesting to simulate the maximum nodes one considers a single entity can throw at the network and what the size of the network means. In other words changing the table to have a constant attacker size and what the total size of the network means. EDIT: If I remember correctly David said that new nodes can only be promoted to have voting rights if the section/group needs another voting node. So if none of the section/group’s nodes leave then no attacking node can get voting rights in that section/group. Is this a consideration for your simulation. (considering that nodes don’t always leave because a new node joins)

4 Likes
11

This is even more an impediment to a Google attack and works like this. The network will only allow 1 new node per section (an infant of age 1)/ This means a huge attacker will need to try over a longer period and hope that no other peers are joining. I hope this helps a bit, btw this poking around is great @mav I try and keep out of it while you guys are poking around so as to not skew the thought process. There are a few things we do and age is a pretty huge part of security, but it hard to simulate properly. If you check @bart s simulations code (form this weeks update) you will see how we has done that part in some testing we have been doing for network startup etc. It may help.

20 Likes
12

This is why I didn’t think that the safe network can work at all. I run this as ‘Amazon Attack’ before. The problem is even more severe because there is a financial benefit associated with running a node.
If the price for running a node on AWS < profit from Safe-Coin it is inevitable that most of the network will be hosted by the big cloud providers which can be coerced easily. It will happen naturally. The only solution I see is to increase redundancy dramatically (similar to reducing the block size until a sufficient degree of decentralization is archived). That, however, would make space extraordinarily expensive (see Bitcoin block space).

13

What makes you think this is possible?

Remember this is the core restraint you have

  • before even looking at what David said in the post above yours.
  • Its even before considering that amazon may do it and then google does it, then dreamhosting does it, then about 100 other datacentres do it. So now you have a distributed network of datgacentres and there goes the attack and the network survives.

But your core concept has a major problem. They have to compete with all the billion of potential home vaults which cost their owners near zero costs. So I still fail to see how an amazon or google can hope to undercut home vaults using their spare resources with virtually zero extra costs to run their vault(s). The billion figure comes from the fact their are billions of computers/devices on the internet and then that people will run 2 or more vaults if they can.

3 Likes
14

I’m somewhat inclined to agree based on my intuition, but I have seen so far that my intuition cannot be trusted, especially once ageing is factored into the attack.

The datachains and ageing algorithm explained in data chains: a deeper dive is currently being added to the simulation I’ve been working on, as well as being added to the very active codebase from bart at https://github.com/fizyk20/ageing_sim (incredible to watch that repo as it develops btw). So far it seems like ageing makes the google attack extremely difficult, but I am trying to reserve my judgement until all the pieces are in place. I’ll hopefully have some more results soon but it takes time to develop the simulation and I am frustratingly time-poor at the moment.

I agree with you that spare resources at the consumer level probably won’t be viable as vaults, but disagree that this means the network will fail.

I think the inconvenience caused by vaults consuming bandwidth will mean most consumers won’t like it (ever had someone in your house start a torrent with no throttle?! it sucks!!). So my feeling is datacenters will be the main place vaults will reside (but probably remote individuals will be in charge of the vaults).

I don’t think cloud providers can be coerced easily. But I’m not a politician or lobbyist so I’ll leave it at that!

5 Likes
15

The Chinese government is a scary potential attack threat if they want to mess with the SAFE network, at least in the beginning when the network still is fairly small. To nip it in the bud sort of.

Maybe MaidSafe should cooperate with the Chinese government! Fat chance perhaps, because of lack of censorship and centralized control, but who knows, just look how the Chinese government has promoted businesses and “free” market economy in recent years, so they may be moving into a more libertarian direction.

16

I think this is easier to ward off than anything complex when the network is small.

We already have the chicken and egg problem with how does one pay for an account. We just need a kinda of gifting or voucher or invite system where people give their friends an invite or voucher to pay for the account setup. This limits the accounts spamming while the network is too small to handle a large number (10s of millions) of account.

Then nodes can be limited to one elder node from a subnet in each section. This way a centralised attacker has little chance of getting enough nodes in any one section to cause damage. Any central ised attacker has only a limited number of subnets they can use and due to the random nature of node IDs its unlikely they will get enough.

Obviously though if an attacker has 10 times more nodes than everyone else in a small network then they are the network arn’t they. So we restart with a new network and leave them to their own network and their coin becomes ChineseSAFEcoin

1 Like
17

Relative to PoW blockchain mining, I would say safe net farming will be more open. You don’t need specialist hardware to take part at some level.

Perhaps splitting tasks by node age could help to disperse power. Having nodes retire from providing some functionality to concentrate on something else may help. If it was something less performance sensitive, it would prevent a hardware arms race to provide this.

It would seem a good idea in general to dispurse performance insensitive operations as wide as possible, but allow performance sensitive operations to cluster around capable hardware.

6 Likes
18

I think there is an element of truth to this, but a lot of people were willing and happy to provide resources to BTC even when it did require some specialist hardware, made a lot of noise and cost a lot in power usage. It requires a big investment nowadays and very few can compete, but the will was there for a lot of enthusiasts. If it had been really simple to do a lot more people would have given it a go.

Considering how fast bandwidth is expanding and how little of it we use most of the time, I’d say a lot of people with little money would jump at the chance to make a bit of free deflationary internet cash or get some free access. In the early days it will probably be more decentralised than later on, but when I look at mining cryptos in places like Venezuela and China I can’t help but think how popular farming would be in situations like that, with cheap infrastructure and little money. I see plenty of reasons to be optimistic about farming staying decentralised ‘enough’, even if a lot of people do run nodes from data centres too.

I also think little SAFE hardware devices like the ant miners will probably become common and ‘cool’. Something that also has a little battery in it in case of a reboot so you don’t lose your node age etc. Imagine if people hearing about BTC now were hearing about SAFE and learning that they could farm it themselves quite easily (more easily than buying BTC these days)? I’d say quite a lot of them would give it a go rather than open their wallets. Some would even rather invest $50 in a littler hardware device they can plug in and make pennies with (ant miners sell at crazy premiums on ebay even though all but the biggest run at a loss). For many buying in is not even an option, but they still want to participate.

Who knows, I agree with almost everything I’ve ever seen you write @mav (the bits that didn’t go over my head anyway :)), but my gut tells me you needn’t worry too much about farming centralisation, even in the relatively long term.

3 Likes
19

@mav what about a “google GET attack” where Google uses their bandwidth to download(GET) an absurd amount of data from the network(as much as possible, deleting the cache everytime) so that every farmer on the network is uploading almost to their max limit, causing their internet connection to be extremely slow(of course, this will probably only happen at early stages of adoption) so they disconnect from the network after let’s say 30 minutes so they can use their internet normally, while many others do the same, and the network’s redundancy mechanism can’t work as well as each farmer is uploading to their max capacity already, to get an additional copy of the file missing due to a farmer disconnecting from another farmer to another farmer, will take a while.

So what end up happening is many farmers who are using their internet regularly will disconnect due to them unable to use the internet normally otherwise, and such an attack will make the redundancy of the network suffer too, so network may end up losing data. If they do it for long enough, lets say a month, many farmers will lose faith in this and safecoin value will drop and more people will start quitting etc etc.

1 Like
20

Not sure what is already planned, or what constraints there is, but I would certainly say that a lever for % usage of machine resources should be a part of safe vault settings.

A simpler variant would be a “gaming mode” that users can toggle on off, so that the vault consumes less resources. As long as it doesn’t totally wreck your node age, it could be a good compromise at times.

With that in place, people would not disconnect, instead just lower resource contribution at the moment they need it.

The google get attack you draft (now not considering what else might render it unfeasible) would be less likely to succeed with the above.

2 Likes