Node and group encryption key management within IPFS ecosystem

[Admin-DataRoads]

Essential Use Cases

• IPFS user creates new IPNS folders, files, and related metadata encrypted for privacy at rest by default; providing local record of functional equivalence between encrypted + key = decrypted blocks, tracked and linked within a locally-immutable IPLD mDAG by their respective multihash content ID's.
• Local Access Control configuration API or command set allows gradual structured key sharing with node peers, or pre-defined node groups in shared lockboxes, in keeping with Capability-Based Security standards.
• Access is granted to the public via structured IPNS manifest distribution, only when global publishing is explicitly intended, using metadata and key-sets signed by the intended public author's public-private key pair.
  • A network consensus timestamp may be applied at time of public signing, in order to help establish public data source attribution and provenance, if desired by the author.

Use Cases

• IPFS user creates new IPNS folders, files, and related metadata encrypted for privacy and only uses IPFS and limited IPNS data distribution for remote backup purposes. Encryption keys are thus only ever held locally and never distributed.
• Local access control configuration API allows gradual structured key sharing with known peers, or among pre-existing membership node groups in shared lockboxes, in keeping with Capability-Based Security standards.
• Decrypted data or necessary decryption keys are only revealed to the public when global publishing is explicitly intended, using metadata and key-sets signed by the public author's public-private key pair, with a network consensus timestamp if public data source attribution and provenance are desired by the author.
  • Upon publication, the node may utilize a group shared public-private key pair to sign all published metadata and keys, in order to gain pseudonymous privacy protection via group membership.
  • Each group lockbox membership or private network is able to collectively determine their own publishing, revocation, membership, local incentives, write access, and blacklist policies via consensus protocol selection and owner/moderator assignments. Each decision will create a different automated control on group node shared key distribution, and map Access Control configuration API calls to Capability Based Security key allocation.
• Nested arrangements and cross-over membership of multiple group lockboxes are possible as a result of key distribution being innately public-private key pair and signature source agnostic. Higher level or external identity confirmation systems are necessary to prevent such complex multi-membership arrangements, as a group defined policy that influences group node Access Control configurations.

Foundational Features + Functionality

• Finish KeyStore and KeyChain systems, and add group lockbox distribution so access is not node dependent..
• Key exchange Access Control configuration and network API establishes private network and group membership status as a result of encryption at rest, over the wire, and maps into Capability-Based Security models.
• Group lockbox membership ad hoc arrangements allow private networks to form, federate, or subdivide at will.
  • Group members may publish data to the public as a unified group identity via public-private key sharing, which should be automated or managed according to each group's predefined publication policies.
• Every request for a key access needs to occur inside an encrypted LibP2P channel or tunnel, and request messages must be signed by a valid group member or known permitted peer public-private key pair.
• IPNS manifest distribution must not permit accidental leaking of decrypted block or key data prior to Access Control configuration API permitted release.
  • This potential leak issue creates a good argument for keeping IPNS manifest data and distribution separate from (but related to) any encryption key records and management. Even releasing the multihash ID of any decrypted blocks prior to permitted publication represents a potential security threat, so the IPNS manifest records should only reference encrypted block multihashes prior to permitted release.

Existing Projects + Organizations Working in this Area

Please note: node and group key management does not create nor enforce any identity or reputation systems directly, but it can enable linking such systems to an Access Control layer as desired by individual group or node owners.

• Private IPFS networks

• Peergos

• uPort

• Sovrin

• spherebox

• Google Circles, Groups, and apps "for Work"

• Dropbox Business

• Backblaze Groups

• GitHub private repositories

• Facebook groups

• Discourse

• Slack

• http://sprout.ics.uci.edu/past_projects/gac/index.html

Additional reference materials: https://docs.google.com/document/d/1htXTZUWPYB3WNsKmvClKQlFn1ByehWTG1WRR5zQkjH8/edit?usp=sharing https://docs.google.com/presentation/d/1Gfu2J4A5tJZP4V4EmSCsYVVx2cuoo56QWmYDe1ldIwY/edit?usp=sharing

[Sulejman]

Is this forgotten, is there a plan or work in progress on implementation of something like this?

[Stebalien]

No work is planned at the moment. If you'd like to see how people currently encrypt data on IPFS, take a look at Peergos and Textile.

Note: This repo contains ideas and discussions, not implementation plans.