Hypercore Access Control

hyper-access-control.md

Acess Control In Hypercore

Allow Lists

One way to revoke access to a hypercore is to control who is allowed to replicate a hypercore.

WHen you create hypercore replication stream you can control when feeds can be added or removed.

As well, after a replication stream is created you can see a peer's remote public key which can be used to securely identify a peer in the network.

With this in mind I propose a flow like this:

• Define a group for access control using a hypercore (controlled by a central writer?)
• Alternately you can hardcode the list of remote public keys in memory
• Replicate the group feed over any connection after the handshake
• Once successfully replicating with the peer get the latest list of peers from the hypercore
• Then check if the peer's remote public key is within the set
• If it is, iterate through all the protected feed and replicate them
• Might be able to use separate corestores for protected and non-protected feeds

const swarm = hyperswarm()

const protectedFeeds = new Set()

const groupFeed = feed('group key')
protectedFeeds.add(feed('exampl-feed1'))
protectedFeeds.add(feed('exampl-feed1'))

swarm.on('connection', (connection) => {
  const replication = new HyperswarmProtocol()
  
  groupFeed.replicate(replication)
  
  groupFeed.once('peer-add', () => {
    const peersKeys = getLatestPeerKeys(groupFeed)
    
    if(peerKeys.includes(replication.remotePublicKey)) {
      for(let feed of protectedFeeds) feed.replicate(replication)
    }
  })
})

With this in place, one can distribute and update allow lists and prevent data being leaked to peers that aren't allowed to get access to the data anymore.

Changing keys

Another approach would be to change public keys for hypercores and to mark them as being invalid.

First, you'll need to change the key for a hypercore.

For that you'l need to do something like this:

• Generate a new hypercore keypair

• Initialize the hypercore with the old keypair

• Go through each block and make a new signature with the new keypair

• Save new signatures for each block on the signature storage file

• Once all the signatures are saved overwrite the public key and private key files with the new keys

• Close the feed and re-open it and run audit to make sure it works

• From then on the feed will only be able to replicate on the new key

• For peers that aren't writers, once they know that a feed has been updated, they should open a fake feed for the new key

• Then send Requests for data and set the flag to only requst the signatures

• Save the signatures in the Response over the existing signature file storage for the feed

• Once you've downloaded all the signatures for your local data, update the public key file

• Then close and re-open the feed and audit it

• Now it can be replicated using the new key

You'll need some mechanism for notifying trusted peers that is secure against whoever isn't allowed to see the channel. In addition you'll need to makr a hypercore as being "destroyed" or invalid so that peers will stop replicating them

This has similar security constraints to the previous method, but still depends on how you notify peers of the changed hypercore.