We recently developed a PDS called Monas at a hackathon organized by PL. We actually built Cryptree to implement read access control. I will introduce a few and write about the issues. If this topic is not appropriate, please let me know.
Introduction
Monas is a Decentralized Personal Data Store (PDS) designed to empower Data controllers with data sovereignty.Under the current circumstances, state-of-the-art technologies like the Semantic Web , Self-Sovereign Identity , and Blockchains are possible to solve the issues of data interoperability and of user-centric data management. Monas enables users to manage their data while maintaining privacy and ensuring interoperability utilizing the cryptographic data structure of Cryptree and Blockchain technology to ensure data authenticity. Unlike traditional ‘solid line data links’, we proposes a new paradigm of ‘dotted line data links’, which directly reflect user intent. This approach allows Monas to create a space in cyberspace that protects both autonomy and privacy, offering users the flexibility to solidify these links at their discretion.
More details:Monas: Privacy, Data Interoperability, and Self-Sovereignty in Decentralized Personal Data Store v1.0.1
Prototype Overview
We’ve developed a prototype that embodies the principles of Monas. This prototype leverages three key components:
- Decentralized Identifiers (DIDs): Unique global identifiers that operate independently of centralized authorities.
- Cryptree: A structure that provides intuitive access control, managed by Data controllers.
- Blockchain: This serves as the backbone for our state management system, ensuring the authenticity and consistency of data.
Our prototype specifically focuses on enhancing the functionality of read access control and the robust management of state.
System configuration
The prototype consists of IPFS , Tableland , Push Protocol , Filecoin and Polygon . The features we implemented in this project are as follows.
Cryptree Algorithm Explanation
In the original Cryptree paper, there are five types of keys, but we have implemented using two types of keys: the Subfolder Key and the File Key . Unlike the method in the original paper, where keys are generated from other keys, we have implemented each key independently. The one of reasons we selected our method is that it’s worth dedicating separate time to the algorithm that generates keys from keys. We’re focusing on implementing Cryptree. We assume that even if we were to implement a process for generating keys from keys, the sequence of operations would approximately remain unchanged. The reason for limiting it to two types of keys is that it optimizes the issues with key storage locations and complexity. Our algorithm solves the issue of key storage locations and we present an intuitively understandable algorithm.
Details more Prototype: here
Issue: Changing root_id with Node Addition and Re-encryption:
Problem: Integrating IPFS results in immutable content addresses. Any changes to metadata or files alter the CID, similar to a hash function.
Solution: We’ve implemented Tableland to link root_id and root_key with specific addresses, ensuring consistent identity management despite changes.
We are using Tableland to do the mapping, but it does not solve the essential problem.
The main problem is that every time we add a file, modify metadata, or rotate keys, we need to re-upload the metadata to the root node. This issue arises from the nature of CIDs. In the future, we aim to build a P2P network, and while I think it would suffice to save the data structure on each peer’s device, this could be challenging depending on the device’s specifications. Therefore, I believe we may need to consider outsourcing certain processes. If you have any good ideas, please let me know.
Also, if you have any feedback or discussions regarding the prototype we developed, please feel free to comment.
Thank you for reading.