Blockchain is considered as one of the popular solutions for decentralized data storage which offers high availability and data immutability due to the use of a specific structure for storing transaction blocks in combination with consensus algorithms. However, the nature of blockchain makes it not suitable for storing big amounts of data, like access control matrices which are typically used by DAC. This research proposes a new access control model based on DAC and RBAC models that is capable of managing access of various users, by storing minimal data in blockchain, and full data off-chain with the help of Merkle trees. A new model was proposed, which allows compressing access control data off-chain, and storing only Merkle root hash on-chain. The article describes DecStore - blockchain-based file storage system and how access control model can be scaled to more than 1,000 users and 1,000 storage objects using a caching mechanism on the users’ side. Experiments were conducted to verify the scaling of the proposed model. Based on the obtained result, it was concluded that the proposed model is applicable to a wide range of systems, including IoT. This model is one of the first to solve the problem of storing large-dimensional DAC RBAC data.
Access control management is considered an essential component in various systems. Whether it is a file storage system, a social media website or any other system which provides access to its private resources, it is required to manage how different parties can access these resources. Many blockchain-based systems are not dedicated for managing access control, but use access control as a required functionality within the system, such as (
Access control can be classified into the following main types ( Mandatory access control (MAC): It is a type of access control that has levels of confidentiality. An example is when resources are classified as {common, secret, top secret}. Thus, users can access resources based on the security level they are granted. Discretionary access control (DAC): in this type of access control, the owner or the creator of the resource defines who is allowed to access it. Usually, DAC uses a matrix access model ( Role-based access control (RBAC): In this type of access control, users have different roles, and resources are accessed based on the role they have. For example, in e-commercial websites, some pages are limited to administrators, other pages can be accessed by managers and administrators, etc. Rule-based access control (RuBAC): This type of access control defines the rules by which resources can be accessed, which can be various. As an example, some banks might put a condition that currencies cannot be exchanged at night. Rule-based access control is usually used in combination with Role-based access control ( Attribute-based access control (ABAC): It manages access by assigning policies for different attributes of users, resources and environment (
It is important to note that in modern systems a combination of different types of access control models is usually used. Corporate and government systems store millions of objects, including financial, social media data, and IoT data. They need flexible and reliable access control methods.
The usage of DAC can be sometimes unavoidable because it might offer more control over data than other systems. For example, sometimes it is required to provide a specific user access to a specific resource, without giving permission to other users with the same role or set of attributes. The problem is that DAC can result in a big matrix of resources against users. In storage files systems, if there are 1 million files in total, and 1,000 users, we will end up with a billion entries, which might be problematic when considering distributed systems with huge data redundancy like blockchain. When considering RBAC, less data is required to be stored, as a single policy can cover many files. However, the resulting data size might be still big, and unsuitable for blockchain storage. The aim of this research is the development of a distributed DAC+RBAC access control model that solves the problem of scaling for blockchain-based systems without centralized components and minimizes the size of the access rights storage in the blockchain.
We will consider DecStore as a study case which is described in detail in a series of articles (
Data storage architecture in DecStore.
It is important to note that the proposed access control model is not proposed to be used with DecStore only. VDs can be expressed in other systems by docker volumes, virtual disks (VHD of virtual machines), folders, etc.
There are many studies that discuss applying access control in blockchain. Most of these studies focus on how to implement access control using blockchain for a specific field, especially IoT (
Another solution (
One interesting method for decentralized access is using zero-knowledge proofs (e.g., zk-SNARKs) (
In this article, we propose a DAC and RBAC access control model which results in minimum data storage size on blockchain, and high scalability without compromising the expected security level of the system or access speed.
The proposed access control model can be summarized as following points: Creating Merkle trees for various storage entities in each physical server Combining and compressing these trees Store only the hash of the total Merkle tree hash for each user in blockchain, instead of writing the access control policy for each file on blockchain User Merkle proof to verify authorization
To achieve an access control model for DecStore that supports scalability and requires minimal data storage in blockchain, the system architecture and storage model can be modified as follows: Each virtual disk (VD) is provided with a unit called “Permissions Storage unit.” For each user who has access to at least one file in the specified VD, a tree is created in this unit. This tree represents files organized within directories which the user has access to by DAC. The storage units located in VDs which belong to the same VC have the same copy of trees. Each storage node has a single tree for each user which represents the combination of his DAC trees in the VDs existing in this storage node. On the blockchain side, each user has 1 hash stored that represents the total hash of his Merkle tree root (
DAC access control data storage in blockchain.
| User | Merkle tree root hash | Roles |
|---|---|---|
| f970e2767d0cfe75876ea857f92e319b | 006d2143154327a64d86a264aea225f3 | Administrator |
| 7694f4a66316e53c8cdd9d9954bd611d | 76d80224611fc919a5d54f0ff9fba446 | Developer, team-leader |
Also, the roles are stored in blockchain in a similar way, as in
RBAC access control data storage in blockchain.
| Role | Merkle tree root hash | Nodes |
|---|---|---|
| Administrator | 0cc175b9c0f1b6a831c399e269772661 | 1, 4 |
| Developer | 8a8bb7cd343aa2ad99b7d762030857a2 | 2, 3 |
A typical flexible access control system is managed by policies and consists of ( Policy administration point (PAP): It is the component that creates access policies. Policy information point (PIP): It is the source which holds the policy information based on which the user’s access is granted or denied. Policy Decision Point (PDP): It is the component that decides whether a user is granted access or not. Policy Enforcement Point (PEP): It is the component that creates a request and sends it to PDP. It collects required information from PIP and other resources, like user request information to PDP Policy Retrieval Point (PRP): This component is not mandatory. It is used only when there are several PDPs and it is required to provide a centralized point for sending or retrieving access policies.
In our proposed model, policy information point (PIP) is not stored on a centralized server. When PDP (which is represented in the system by a blockchain smart contract) makes a decision, it retrieves information from two entities: the user, and the records stored on the blockchain. The full access information is stored on the storage nodes, and users synchronize their own access trees with the ones located on the storage nodes. Policy Enforcement Point (PEP) which is also represented by a smart contract, sends to PDP the Merkle tree proof from the user request along with the according expected Merkle tree root hash.
Thus, PIP is represented by three entities: The distributed network of storage nodes, which have the full policies, and are used only to allow users to sync their policies. Users side, where each user stores his policies whether it is DAC or RBAC. Merkle tree root hashes for both users and roles, which are stored on the blockchain.
Users’ trees consist of three types of nodes:
Root–it represents the Merkle tree total hash.
Leaves: represent the files (or directories, in case the policy allows the user to access all files in a directory instead of selecting files manually). They can have an optional value “compressed.” We will discuss it in the tree compression algorithm section.
Intermediate nodes: they can be directories or combining nodes. A combining node is the node which combines two nodes of various types, where any of those two nodes can be a leaf, a directory or a combining node. This type of nodes will be discussed further in “Building binary Merkle tree” section.
Each tree node contains two associated data structures: Hash and value. Hash represents the hash of the value.
Nodes’ types and structure description.
| Node type | Node structure | Example | Hash |
|---|---|---|---|
| File | {Name = “File name,” Type = File, Access = “Access type,” Compressed = “compressed paths,” Path = “Path”} | {Name = “document.pdf,”Type = File, Access = R, Compressed = Path = “/documents/”} | aa72770681fa71958b02cf5511182f1fbae25efc9b361d0ebc0e533ed6842e64 |
| Directory | {Name = “Directory name,” Type = Directory, Access = “Access type,” Compressed = “compressed paths,” Path = “Path”} | {Name = “documents,” Type = Directory, Path = “/”} | c5f503118d94f8e81085329abca5b4a21b64e2981548b13308f0a8282ba82cb8 |
| Combining node | {Type = Combiner, Paths = [“paths array”]} | {Type = Combiner, Paths = []} | 4c8d6d1c41e8740161f9353aa6d70a577e7d25f98ba9de1002dd851a8d016365 |
DecStore architecture with proposed access control model.
The main outlines of the method can be described as follows: An access control tree for each user is created in each storage node. It has the set of files in this node the user has access to, which exist in VDs of a specific preselected index. For each user, all trees from VDs in a node are combined to a single tree, compressed and converted to a binary tree. These trees are used for DAC ( Also, each storage node has several role trees. There is an extra copy of each role tree, which is located on a different node. All storage nodes have the same number of trees. Blockchain distributes the trees and their copies on the storage nodes. Users synchronize their trees with the ones existing on the storage nodes. This includes their personal trees (DAC) and the roles trees (RBAC). Users use their copies of trees to access files by generating Merkle proof. See Blockchain handles processes related with distributing and the recovery of trees in different situations, in order to grant that the system stays balanced, and that files are recoverable, or recovered automatically to another node when a storage node is lost.
This algorithm has three main phases: In each VD which is selected by blockchain, a tree for each user is created. This tree shows which files a user has access to in this VD. Each node combines these trees into a single tree, which represents which files the user has access to in this node. In the combination process, files from different trees that are located under the same folder get combined under a single tree node. The tree gets compressed after that, by combining tree nodes which have a single child into one tree node, in order to minimize the size of the tree ( The resulting tree is converted into a binary tree, in order to minimize the size of Merkle proof (
Users’ access information is distributed across storage nodes using VDs. This means that data is replicated in VDs that belong to the same VC. When creating the combined Merkle tree, only one of the VDs of each VC participates in this process to avoid redundancy, which means that it is required to choose which VD will participate in this process. Selecting a fixed VD for all users is not practical, because it means more load on specific VDs, while it is preferred to distribute the load over VDs. Assigning a set of VDs for each user is not the best practice, as this means extra data storage in blockchain. The selection of VD in this algorithm is dynamic, based on the formula:
If the resulting number is 1, it means that only the first VD in all VCs is selected for building the tree for this user. If it is 2, it means that the second VD is used. If it is 0, it means that the VD which holds the Erasure Coding is used. The initial treeNode in the algorithm is the tree root node.
Trees are represented using sets of sets, where the main set is the tree root, and the elements of this set represent child nodes of the root (files and directories), and they are also sets that represent the same concept. These sets (tree nodes) have attributes (name, type, etc.). Files are represented by empty sets with attributes. We will use the words «tree nodes» and sets interchangeably. In each storage node, trees are selected based on the selected VDs (based on the selected VD index), which will be combined to build a single tree on the level of the storage node. The tree node is expressed by the set
Which means that it can have items from different trees under the same directories, or it can be a single item if the directory has one file only.
Let’s assume that in storage node 1 there are three VDs: VD3-P2, VD5P1 and VD6-P2. Let’s assume also that the selected VD index is 2. In that case, only VD3-P2 and VD6-P2 are chosen. Now, if the according trees are shown as in
Separate VDs trees example.
User 1 combined tree of VD3-P2 and VD6-P2.
The combination process repeats for every tree node in the list, and the join function is performed on all the resulting tree nodes as well until there are no more child nodes. The used notation shows that tree nodes that have the same name attribute are combined with each other and added to the TreeNode, as well as tree nodes that have unique names.
As the current study case considers DecStore, in other systems term VD can be replaced by “virtual machine,” or any unit that allows logically separating files on one server (ex. folders). If files are directly stored on the server, this means that the algorithm of combining trees is not required.
After that, compression algorithm is called. This algorithm is required to minimize the size of the tree, by compressing tree nodes which have a single direct child into one, resulting in a smaller tree in total. This means that directories which have only one object (a file or a directory) are compressed into one. Joining two tree nodes into one is described by the formula:
“Compressed” attribute in the tree leaf represents the path of compressed tree nodes if they exist. “Access type” and “compressed” attributes in the case of directories are used only when the policy allows the user to access all files in a folder, so in this case, the directory is a leaf. Starting with the root node, the compress algorithm runs in a top-bottom model.
The compress function for a parent tree node is defined by the formula:
The compressed tree version of the tree presented in
Compressed tree example.
The next step is converting the compressed tree into a binary tree. In order to perform this step, a new type of Intermediate nodes is added (combiner). Combiners are used to combine child nodes in such a way that only 2 tree nodes are considered as direct child nodes. This type of nodes has “paths” attribute. This attribute is set if the combining node has a directory in one of its direct descendants which are not combining nodes.
An example of the usage of paths attribute.
In combiner 3, “paths” value is doc and ppt. That is because it has two direct folders: doc which is a “compress” value for the nodes doc/1.doc and ppt. Folder 2023 is not added to paths, because it is a child node of ppt, which is already added in paths. When accessing 2.ppt, given that the full path is/files/ppt/2023/2.ppt, Combiner 3 is directly accessed because in paths it has ppt. And after that, 2023/2.pdf is accessed directly.
Converting the tree into a binary tree is important in order to decrease the size of Merkle tree proof. Let’s consider the tree example in
Example of a tree that does not use combining nodes.
Merkle Proof of the file 1.pdf requires checking 33 tree nodes: 1.pdf + hashes of all pdf files + hash of doc directory. If we convert the tree to a binary one, it will require checking 7 nodes only: 1.pdf + hash of 2.pdf + hash of 4 combiners (combiners 2 + 18+26 + 30) + hash of doc directory as in
Example of a tree that uses combining nodes.
Converting tree to binary algorithm.
Once all the storage nodes build the user’s tree, the root nodes are combined the same way using combining nodes to build a single Merkle tree. The hash of the resulting root node of this tree is stored for each. Let’s consider building a Merkle tree for RBAC. For each role, a tree gets built. A role tree contains the files to which the policy associated with this role allows access. The same type of tree nodes and attributes proposed for DAC are used in RBAC. Roles get duplicated, and distributed across storage nodes, where a storage node cannot hold a role and its duplication. Each storage node holds
This algorithm is used to verify whether a user has access to a file or not. When a user sends a request to access a file, whether the request is for reading or writing, he sends a Merkle proof along with the request. The body of the request depends on the access method used for this file.
The header of an access file request.
| DAC | RBAC |
|---|---|
| {Access = “DAC,” MerkleProof = […], FileInfo = {…}} | {Access = “RBAC,” Role = “Role type,” MerkleProof = […], FilleInfo = {…}} |
Each user has a copy of his own personal tree + a copy of the role(s) tree(s). The first step is to locate the file. This process can be done using a top-bottom method without searching for all possible tree nodes as in Depth First Search (DFS) (
Once the user selects the file from the according tree, he sends the file info along with Merkle proof to the load balancer, represented by a blockchain smart contract. Blockchain smart contract first checks the access type, and hashes the file info, and then calculates the hash of the sum of the file info hash and the first hash in Merkle proof array and repeats the process for all hashes in Merkle proof array. After that, it compares the resulting hash with the stored one in
The user sends the file value without hashing it, and the Merkle proof array (required tree nodes) P = {P1,P2,P3, …Pn}, where P1 is the required file info value, and P2,P3,…Pn are the hashes of the required tree nodes for Merkle proof.
Assuming that hash(x) is the hash function, Merkle tree hash from the Merkle proof can be calculated using the recursive function
When the user sends a request to access a file, The type of access sends (RBAC or DAC) is also sent along with Merkle proof. Thus, the system understands which entry is required to be compared with, as seen in
Algorithm of resolving type of access.
When a user gets granted or revoked to access a file f, or if the access type changes (read/write), this file gets added/removed/updated in the access tree in the according VD. Changes get propagated to the combined tree and to the total Merkle root hash. The user can detect changes in his tree by comparing his total Merkle root hash with the one stored in the blockchain.
The same algorithm is used. If the user role gets changed, the tree gets updated, and the user detects that by comparing the role Merkle tree root hash stored in blockchain with his stored version of roles. If the user gets a new role added, the user requests a copy of the role Merkle tree from one of the storage nodes that host it, and the tree checks from the blockchain if the user has this role or not before sending it back. If the user loses a role, the role gets removed from his entry in blockchain, and thus access gets revoked.
In order to estimate the performance of the algorithms, an application which implements the proposed method for DecStore was developed. The application was written in C++ with the help of QT open-source platform, and the trees were represented in two different ways: SQLite files and JSON files, as the implementation technologies affect the performance results. The application was tested using a laptop running Ubuntu 22.04 LTS on core i7-8575u CPU and 16 GB of RAM. The experiment included creating two user DAC trees from scratch consisting of 500 new files each, in order to create the combined tree. SHA-256 hashing function was used to create nodes hashes. The test was performed automatically 100 times. The mean time for this process is 9.48 s in case of using SQLite, and 0.55 s in case of JSON files. Total tree size in case of SQLite is 249.9 KB, while it is 552 KB when using JSON. The implementation included combining 2 trees into one, compressing it and converting it to binary, and it is available here (
In real life applications, DAC is probably much smaller than 1,000 files per node, as access is usually granted based on roles, and also by applying policies to directories and their subdirectories, instead of selecting individual files one by one, which means that the size of the resulting trees is supposed to be smaller.
In order to evaluate the performance of the system compared to other possible implementations, 3 systems were considered for testing: 1- Centralized system: Laravel PHP framework was used to implement it, as it is considered as a popular framework for implementing APIs. MySQL was used for storing access policies. 2- Blockchain Hyperledger: Where data is stored directly in blockchain instead of using an external resource to store policies. Docker was used for Hyperledger nodes. 3- DecStore: which is an implementation of the access control model proposed in this paper.
1,000 files entries were generated, as well as 1,000 users. All users were given access to all files (1,000 × 1,000). Three test cases were performed: 1- Granting a new permission to a file: Which expresses the speed of adding a new access rule for a user x to a file y (1 × 1). 2- Revoking a user’s access completely: Which means revoking all types of access given to a user x to any file in the system (1 × 1000). 3- Validating access: It is the timer required by the system to check if a user x has access to a file y (1 × 1).
Obtained experiment results are shown in
Performance tests results.
| Operation | DecStore | Blockchain (ms) | Centralized system (ms) | |
|---|---|---|---|---|
| JSON (ms) | SQLite (ms) | |||
| Granting a new permission to a file | 157 | 190 | 100 | 60 |
| Revoking a user’s access completely | 400 | 300 | 300 | 60 |
| Validating access | 130 | 140 | 100 | 10 |
Another experiment was conducted in order to understand how much storage can be saved when applying the proposed method (DecStore) against storing data directly on blockchain. For this experiment, we considered the case of RBAC. 100 roles are created, along with 1,000 files. Each file can be accessed using one of 10 roles, from these 100 roles. Hyperledger Fabric (Blockchain) is used in this experiment, as in the previous one. The size of data is obtained from the peer nodes, be checking the size of the stored blockchain blocks: − In case of using DecStore: 592 KB − In case of using Hyperledger Fabric directly: 5.4 MB
It is important to mention that the roles were assigned directly. It is clear that the storage size in DecStore is significantly smaller than storing on Blockchain directly. Consecutive updating roles and adding more files will result in much bigger size when using Blockchain compared with Decstore. For example, adding or revoking a role from the whole system will require updating all affected files entries on blockchain to add/revoke the required role in the case of Blockchain, which is time consuming and results of having many transactions (storage size), while in DecStore, one transaction is required, which adds–remove the role hash.
Based on the performance tests results, we can conclude that the speed of the proposed system in various operations is not by far behind other systems, while it supports scalability unlike other systems. Also, it is clear that JSON files can be a good way to represent the trees. However, the performance might differ when implementing using other stack of technologies.
The presented model has a number of advantages over the solutions discussed earlier in
When adding new access to the user’s combined tree, running the compressing algorithm and converting the tree to a binary can be performed faster than when creating from scratch, as the tree might not require compressing at all, and the result of running the algorithm of converting the tree to binary can end up with adding few nodes without changing most of the nodes as it is already in binary form.
Threats were analyzed using STRIDE modeling framework ( Spoofing: If the attacker were able to spoof the Merkle proof, he would not be able to use it to access data (as in replay attack), because the Merkle proof’s hash is verified against the users’ identity value, which is tied to their wallet. Additionally, manipulating nodes data by colluding nodes is not possible, as the network is permissioned, which means that outsider nodes cannot join and provide fake data, which prevents against attacks such as Sybil ( Tampering: If a user attempts to change his local tree copy by adding access to a file or changing the type of access from read to write, then the resulting Merkle proof will differ from the one stored on the blockchain, and access will be denied. Repudiation: If a user’s access to a file was revoked and he does not allow updating his local tree and sends the Merkle proof he had before the revocation, he would not get access, as the Merkle proof does not match Information Disclosure: If the attacker were able to copy the Merkle tree cache from another user, this would not be enough to access data, as he has a different identity. The attack can only succeed when he also steals the identity (wallet) of a user. Denial of Service (DoS): Such a problem is considered when the attack is performed against a storage node rather than a blockchain node, as blockchain nodes are replicated. However, it is required to attack two nodes which have VDs that belongs to VCs that are shared among those 2 nodes to stop data availability. Elevation of Privilege (EoP): Users cannot self-assign data access. Permissions must be granted by data owners. Additionally, it is possible to track who has access to a specific file using trees built in storage nodes, and access of unwanted users can be revoked.
However, the proposed system has some limitations: Users are required to synchronize their trees regularly, in order to access the system. However, synchronization does not mean copying all the users’ trees. Changes can be detected by comparing the total hash with the one stored in blockchain. In case the hash is different, the node which has the modified tree can be detected by its hash. Frequent changes to access rules means frequent synchronization of changes and running the associated algorithms. However, access can be assigned by directories instead of selecting individual files, and RBAC can be used in some cases instead of DAC, which can effectively minimize the number of required processes. Time of revoking a user’s access operation is relatively long, which means that the proposed model is not suitable for systems where frequent deletion of the access rights is necessary. Deployment: Results and performance depend on the system settings, like the chosen blockchain network, which directly affects various parameters, such as transaction speed, gas cost, smart contracts, etc. Additionally, the system has several components, which may necessitate additional deployment time to ensure proper configuration and integration.
In this research, we proposed a new access control system that can work with blockchain in combination with off-chain storage with caching on the users’ side. In this system, a part of the PIP data is stored on the users themselves who request authorization, yet the model uses Merkle tree root hashes stored on the blockchain to prevent data manipulation. The proposed model uses a distributed system for access control management and provides the mechanism for maintaining data fairly distributed in several cases, including adding or removing storage nodes. The access control model consists of several algorithms which allow managing access control in different scenarios. The caching mechanism reduces the number of required requests, which means less pressure on storage nodes. Also, it means less response time, as the decision is made in blockchain itself, without requesting more data from the storage node.
As experiments have shown, the proposed model is scalable and minimizes the size of the rights storage in the blockchain several times. However, the provided tests are implemented on a local machine, and we plan to perform stress tests on the cloud in the future.
This study considered a distributed file storage system (DecStore) as a study case. However, this work can be adapted to fit other types of systems that use blockchain and off-chain storage to store any type of data. The approach proposed here does not depend on the method of encoding or restoring data, but considers the issue of reducing the dimension of the DAC matrix and the distribution of this data in blockchain-based systems.
In future, we plan to work on integrating this access control model with other technological platforms and study the outcome of such integration.
Publicly available datasets were analyzed in this study. This data can be found here:
OH: Validation, Conceptualization, Writing – original draft, Visualization, Software. IT: Supervision, Writing – review and editing, Conceptualization.
The authors declare that the research was conducted in the absence of any commercial or financial relationships that could be construed as a potential conflict of interest.
A correction has been made to this article. Details can be found at:
The author(s) declare that no Generative AI was used in the creation of this manuscript.
All claims expressed in this article are solely those of the authors and do not necessarily represent those of their affiliated organizations, or those of the publisher, the editors and the reviewers. Any product that may be evaluated in this article, or claim that may be made by its manufacturer, is not guaranteed or endorsed by the publisher.