Trust system and automatic defense

[rmader]

Assuming that

• one of loklaks main usecases is to run as collaborative network (allowing unknown parties to participate)
• we're doing a lot of work to make automatic deploying of loklak instances as easy as possible
• loklaks goals stand in opposition to interests of competitors and maybe other parties
• mashines make errors / may send broken data

I think it is nessecarry to think about automatic and efficient messurements to protect loklak intances of attacks, manipulation or just errorneous data.

This is a topic which cannot be seen as generally solved (as far as I can tell). But I'd like to propose an idea which, in my opinion, would fit well into loklak and, if implemented rightly, drive up cost for an attacker significatly and also would automatically filter errorneous data.

Idea

As loklak works collaboratively but also centralised, the idea is to have a hierachic trust system were a loklak instance assigns different levels of trust to contributing peers, and based on this, can deside which data to show where. For example, if one wants to create a twitter wall on loklak.net, it's maybe desireble to only show messages from trusted peers, not from completely unknown sources.

Trust list

• Each instance recieving data from outside (like loklak.org), I'll call it server later on, sets up a trust list where all contributing parties (peer later on, note that a peer can be a server for others at the same time) are ranked with a level of trust, for example 0-100, with 100 being ultimativly trusted and 0 being effectivly blacklisted
• Each new peer would start with low, neutral level of trust
• peer can gain or lose trust by different ways (see further below)
• a server can decide to serve only data from peers above a certain trust level. Data from this peers would already be stored before they reach it, but only made public as soon as the peer "proofed" to be trustable enough

  Gaining trust

Peers may gain trust by:

• manual setting (for example all peers directly controlled by the loklak team could have ultimate trust for the loklak.org server)
• Time: a peer running for month already would be higher trusted than one just setup a few minutes ago
• Double checking: when different peers harvest the same messages, we can compare them and in case of missmatching, apply one of the following
  • Trust the one with higher trust level, trust pernality for the less trusted
  • Majority: if we have more than two, trust the majority (in numbers or trust)
  • Check: let the server (or a some other instance under its control) check again and act as judge. Trust gain/lose for the respective peers
  • Notification: emails and other notification for admins could be send for manual checking
  • ...
• ...

The reactions on the double checking could be case specific. For example, if the difference in trust between the peers is very high, just apply the first one. If they are similar, maybe better check.

Samples

It would even be easy to have a dedicated, trusted instance which proactively checks peers, making systematic samples

More ideas

To make this system work, it would be good to have unique identifier for each peer and maybe also signatures on the messages passed to the server. This could be done by automatically creating a pair of private/public keys on first run of every instance.

Also, to make sure attacks are costly, each new peer could be forced to make a one time 'handshake' with the server, where the peer has to do a computationally expencive tasks. This would not harm long running peers, but would make it hard to create thouthands or millions new faulty peers for DDoS like attacks. Should of course not always happen if somebody starts the program on her local mashine, I'll come back to this.

Disadvantages

• Performance: as today encrytion/signing/checking is a very common task, the performance pernality to do all this things should be very limited (java 8 does again better here than java 7)
• Users: as most/all of this should be possible in an automatic manner, it should not have any disadvantages for admins/users.
• Errors: of course this could lead to errorneous blacklisting of good servers (false negatives). Overall, it has to be done carefully, of course

@mariobehling @Orbiter I'd personally like to work on this for the gsoc, together with general savety meassurements all over the project, see #340

[Orbiter]

Thank you for this intensive analysis. That is all useful and should be considered in the context of a larger infrastructure using user authentication.

As a basic fraud prevention we currently have client hashes attached to messages. 'bad' messages can be removed from the data based on those hashes. I admit that this is incomplete.

We want an easy-to-setup system where everyone can start a loklak network and join other networks without much configuration. We must make sure that new quality ensurance methods can be added as an option. Maybe such options should be default for loklak.org, but not for ad-hoc new loklak networks to keep it simple.

I will consider all of these suggestions as work points later in the context of an overall authorization and authentication framework.

[rmader]

Thank you @Orbiter Just a little demo what could easily happen right now: loklak_fake

[Orbiter]

more Ideas: use trusted certificates to authenticated peers according to https://github.com/loklak/loklak_server/pull/351

[Orbiter]

another idea: use accounting details according to https://github.com/loklak/loklak_server/issues/363#issuecomment-220008513

[smokingwheels]

This might help in realtime. Detect acceleration of number of messages from a peer over time period. Create a stack in HZ x deep of how often a peer sends a message to loklak.org. 1/Frequency create array and look at the history in seconds. The Period is linear with change. See Compare the period 10 or so cycles back in time. Generate a trate! value for a peer.

trate! = (history in seconds - current in seconds) / period in seconds current rate * some scale that varies with trust over time.

Straight from my engine program. Only made the engine ping when accelerating. If you take the negative value it makes the tyres chirp intermittently with drive train natural resonance #Fun.

trate! = ((timecyc(rpmadv10) - timecyc(rpmadv)) / degcyc(rpmadv)) * trscale!

The trscale! could be adjusted by increment or decrement a small amount on a 1 second time scale depending on the value of trate!, you would also have to add "#stumpjumpers" if trate! exceeds a positive preset value.

I will think about this post and dig up my old program and check it for a better summary into its operation. I still have a car and can get it running if needed Here Its far quicker to put a timing light on the formulator and see what it does. Even quicker if you drive it. I have a paddock.
@Orbiter

[Orbiter]

good ideas! Here is another thing we should do in that context:

• create secure peer hashes. We developed a concept for that for YaCy, but never created them because we alread had hashes.

I will open up an issue for secure peer hashes.

[Orbiter]

The storage of peer hashes and public keys will be implemented with https://github.com/loklak/loklak_server/issues/470