Strong Deniability on content replication and consumption in P2P networks

[gpestana]

We need last mile P2P caching which does not disclose what nodes are consuming. We need protocols for scalable storage and distribution in P2P networks with strong deniability, i.e. the peers which perform caching can provably and strongly deny that they are interested in the content they are providing.

Commonly, If a _nodea is interested in content X stored in the network, it will 1) request the network peers for it with lookup(X) and 2) replicate it locally. Problems with this approach: _nodeb can claim that _nodea is interested in content X if he intercepts a lookup(X) from _nodea or if _nodea replicates X. In this example, _nodea leaks metadata in respect to its behaviour. In practice, it broadcasts to the world what content it is consuming, leading to exposing people to targeted political, social and economical attacks based on their profiles.

The generalised problem is the following: how can a network of nodes distribute and request content among themselves without leaking information about their behaviour to other peers?

Related:

• inference attacks on peer-assisted CDNs
• Anonymity in Peer-assisted CDNs: Inference Attacks and Mitigation (paper)

[gpestana]

One way to achieve this is build a protocol which replicates data requested in the (network) neighbourhood regardless of the fact peers are interested in the data.

Imagine a tracker which keeps a log of the content stored in the network and which peers are storing it. A peer requests pointers for a given content from the tracker. The tracker replies with a set of peer-blocks data structures, which maps a set of resource blocks to a peer which is caching it. The set of peer-blocks is constructed by the tracker so that when the requester peer issues the network requests, it is not possible for adversaries to distinguish between replication and consuming patterns. This also ensures that network content is available and replicated.

[gpestana]

open questions

• How to enforce this protocol in a completely decentralised way?
• Can it deliver the performance and latency gains that peer-CDNs do?
• What are the optimal replication schedulers to enforce privacy?

[gpestana]

Content Resolver with Interest Obfuscation in P2P networks (CRIOP2P)

An obfuscation scheduler is an algorithm that schedules content replication in P2P networks so that:

1) scheduler resolves location of a resource in the network; (while) 2) peers can strongly deny they have used/are interested in a resource requested and cached (i.e. peers do not leak behaviour* information) 3) requests are latency sensitive (i.e. the scheduler gives priority to peers which are closer and thus with smaller communication latency)

* behaviour is defined as what network content a peer requests from other peers based on its preferences

API and interfaces

// config parameters
const (
  // response will include 0.5*blocks that are not part of the original
  // requested resource
  obfReplicationF = 0.5
  // each peer will be responsible to provide up to 25% of a resource
  peerSpreadingF = 0.25
)

type Scheduler struct {} 

type Peer interface {
  ID() string
  LatencyBetween(Peer) (uint, error)
}

type Block interface {
  ID() string
}

// keeps a mapping between a peer and a set of blocks. peer with `peerId` 
// is storing blocks with `blockId`
type PeerBlocks structure {
  peerId string
  blockId []string
}

// getProviders returns a set of PeerBlocks for the requester to resolve. 
// the set of PeerBlocks is constructed based on the requester neighbourhood,
// the content already cached by it and the resource requested. 
// upon receiving a []PeerBlocks, the requester requests the blocks from the peers
// indicated in the set in order for 1) eventually acquire the requested resource while 
// 2) not leaking information locally as of which content is being requested 
func (s Scheduler) getProviders(neighbourPeers []Peer, cachedContent []Blocks, resourceId string ) ([]PeerBlocks, error) {}