Uploaded image for project: 'MaidSafe-Core'
  1. MAID-3282

Fix possible bias of the concrete coin mechanism with fake Responses sent to fake Requests by malicious nodes

    Details

      Description

      We have identified a possible attack that would allow a malicious node to influence the concrete coin process in favour of them deciding the coin value. If exploited 100% of the time, with full knowledge of every other node's point of view, it could be used to affect Liveness of the protocol; e.g: stall consensus forever.

      We already have plans for mechanisms that forbid DuplicateResponse s to the same request: https://maidsafe.atlassian.net/browse/MAID-3091 and another mechanism to forbid InvalidResponse s, e.g response to an event that isn't a Request: https://maidsafe.atlassian.net/browse/MAID-3088 .

      However, we spotted an alternative way to send many Responses in a short time: create many gossip events with cause Request even though the author of these Requests hasn't actually sent a request.

      To address it, we need to add a way to detect "fake Requests" and punish their malicious authors.

      We discussed a few implementation options and here is our preferred route at the moment (performance analysis may make us investigate other routes as necessary).

      • While sending a sync request, each node will create an event in their graph with cause: cause::Requesting(RecipientId)
      • Any event with cause::Request where the other_parent doesn't have cause::Requesting(RecipientId) where the RecipientId is the author of that event with cause::Request can immediately be identified as malicious, with malice type InvalidRequest. This is a provable type of malice so the author should be punished as soon as the information propagates.
      • When receiving a sync response, the recipient will create an event with cause::Response as previously; however, they will first ensure that the event with cause::Request is the unique such event created with that specific other_parent [1]. If the Request is not unique with this Requesting ancestor, an event with cause::Response won't be created, but instead an event with cause::MaliceAccusation(DuplicateRequest) will be created and that type of malice too is provable which means the offending node should be kicked out as soon as the accusation spreads.
      • Accomplice detection should also be covered for InvalidRequest and DuplicateRequest
      • This changes the topology of a gossip graph so we will need to update the tests with hard coded graphs (in dot format)

      [1] Note: here is a way to implement detection of DuplicateRequest

      • check the tip of the gossip graph for the node who sent the response. It should contain a Request event
      • check its other_parent. It should have cause::Requesting(response author)
      • iterate over the events created by us from that event on. For any event with cause::Response, check that this event's other_parent's other_parent is not the event with cause::Requesting we are iterating from
      • If it is, DuplicateRequest was detected
      • If we reach the latest event we created without hitting such a case, we're good to create an event with cause::Response

        Gliffy Diagrams

          Attachments

            Activity

              People

              • Assignee:
                fraser hutchison Fraser Hutchison
                Reporter:
                pierre.chevalier Pierre Chevalier
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Start date:
                  End date: