Enforcing Cryptographic Distributed-VCS Access Control with No Trust on Servers Xin Xua,∗ , Zhen Yangb , Quanwei Caic , Jingqiang Lind , Liangqin Rene , Bo Chenf and Yongfeng Huanga a Department of Electronic Engineering, Tsinghua University, Beijing, 100084, China b School of Cyberspace Security, Beijing University of Posts and Telecommunications, Beijing, 100876, China c Beijing Zitiao Network Technology Co., Ltd., Beijing, 100098, China d University of Science and Technology of China, Hefei, 230022, China e Department of Electrical Engineering and Computer Science, University of Kansas, Lawrence, 66045, USA
arXiv:2607.29417v1 [cs.CR] 31 Jul 2026
f Department of Computer Science, Michigan Technological University, Houghton, 49931, USA
ARTICLE INFO
ABSTRACT
Keywords: Access control Distributed system Version control Git Attribute-based cryptography Smart contract
Version control systems (VCS), including central VCS (CVCS) and distributed VCS (DVCS), are widely adopted to manage changes to software code and various types of documents. Unlike CVCS, where entities obtain data from a central server, each entity in DVCS stores the entire repository and shares it independently. In VCS, existing access control schemes require the participation of a central server and cannot be deployed in a completely distributed scenario. Additionally, these schemes often fail to enforce fine-grained access control for write permissions, which is crucial for collaborative work in a distributed environment. In this paper, we propose a distributed version control system access control scheme (named DVAC), which enforces cryptographic access control on distributed user nodes based on attribute-based encryption (ABE) and attribute-based signature (ABS). DVAC is designed to enforce a cryptographic access control protocol for DVCS, which enables file granularity read and write separation access control without the support of a central server. To ensure the integrity of the core version control functions in DVCS while protecting data security, DVAC incorporates a version control adaptation protocol. Additionally, DVAC leverages Ethereum smart contracts to maintain access control policies, ensuring distributed storage and trusted management of access policies. The architecture of DVAC is designed to seamlessly integrate with existing mature DVCS, such as Git, with minimal modifications. We have implemented a prototype of DVAC and integrated it with Git. A comprehensive performance evaluation was conducted to assess the overhead introduced by DVAC, and it was demonstrated that the overhead is modest.
1. Introduction Version control systems (VCS) are crucial for managing data changes and enabling project collaboration. They can be standalone or built-in. VCS can be categorized as central (CVCS) or distributed (DVCS). CVCS, like CVS [9] and SVN [33], rely on a central server for reference versions, with clients synchronizing their modifications. DVCS, such as Git [14] and Veracity [36], use a peer-to-peer approach, where each peer maintains its own repository with a complete change history and synchronizes with other peers. DVCS are more efficient and flexible than CVCS, as they eliminate single points of failure. In DVCS, each entity works on its local repository and performs common operations without communication. Entities can create, maintain, or delete local branches independently. They can also choose which modifications to share and store copies pulled from others, providing data backup and avoiding single points of failure. DVCS introduce novel challenges to data access control. In this decentralized system, peers have the ability to exchange modifications directly, circumventing the need for a central server to enforce access control policies. Moreover, collaboration in DVCS necessitates the segregation of read ∗ Corresponding author
[email protected] (X. Xu)
ORCID (s):
X. Xu et al.: Preprint submitted to Elsevier
and write permissions, thereby amplifying the complexity of access control. The intricacies of access control in DVCS can be succinctly encapsulated as follows: 1) Inability to depend on a central server; 2) Uniform implementation across all peers; 3) Separate control of read and write permissions. Existing access control schemes for cloud storage and CVCS [27, 35, 38, 22, 25] are not applicable for DVCS because they require the cooperation of a central server to enforce access control. For example, schemes based on proxy re-encryption [35, 38] and attribute-based cryptosystems [27, 22, 25] all rely on a server for various tasks such as reencryption, verification, and signature checking. Distributed access control schemes [30, 43, 21, 47, 12] also do not meet the requirements of DVCS, as they lack support for write permission control, which is essential for collaboration. These schemes primarily focus on preventing unauthorized read access to sensitive data. However, they are not suitable for DVCS. The distributed read and write framework Disac [42] lacks efficient metadata management and experimental verification. Current access control schemes for Git [31, 3, 5, 41] also face challenges in extending to distributed scenarios, lack write access control, rely on a central server, or involve excessive key maintenance overhead. Therefore, none of the existing access control schemes can effectively address the access control difficulties in DVCS. Page 1 of 14
Enforcing Cryptographic Distributed-VCS Access Control with No Trust on Servers
In this paper, a novel distributed access control scheme named DVAC is introduced, specifically tailored for DVCS. DVAC utilizes attribute-based encryption (ABE), attributebased signature (ABS), and smart contracts to achieve its objectives. The contributions of this work are summarized as follows:
we describe how to integrate DVAC with Git in Section 5. The security is analyzed in Section 6, and the implementation details and evaluation are provided in Section 7. Finally, Section 9 concludes this paper.
• DVAC provides enforced cryptographic access control for a fully distributed VCS. DVAC can consistently control access to files on distributed user nodes without requiring a central server’s involvement. DVAC provides granular access control for each file, with permissions specified by the data owner to define the data scope and its corresponding access control policies. The access control policy is managed in a distributed and trusted manner by an Ethereum-based smart contract, ensuring consistent multi-node control and distributed access control implementation.
DVAC employs ABE and ABS to enforce access control for read and write operations in DVCS. Furthermore, smart contracts are utilized in DVAC to guarantee the availability and integrity of the access control policy. This section provides crucial background information on DVCS, ABE, ABS, and smart contracts, and concludes with a summary of pertinent research in the field.
• DVAC provides a read and write separation access control protocol and a version control adaptation protocol for DVCS, ensuring data security without disrupting the normal functions of DVCS. We implement readwrite separation access control based on attributebased encryption (ABE) and attribute-based signature (ABS). Users whose attributes do not satisfy the read policy cannot decrypt the ciphertext associated with the data, and modifications made by users whose attributes do not satisfy the write policy are rejected and not accepted by other users. DVAC offers an adaptation protocol for the core version control function of DVCS, ensuring cryptographic protection for data in the repository and on the network, without affecting the version control operation in the work-space. As a result, DVAC prevents unauthorized manipulation of data stored by individual peers without undermining the efficient and flexible version control and collaboration provided by DVCS. • We implemented the DVAC prototype integrated with Git, offering trusted metadata management combined with the Ethereum blockchain and lightweight key management, regardless of the number of users. DVAC’s architecture is highly compatible with existing DVCS and requires minimal configuration. Each access control policy is uniquely associated with the data (i.e., files), and a smart contract is utilized to ensure that the access control policy remains under the control of the data owner while being accessible to all entities. We have successfully implemented a prototype of DVAC and integrated it with Git, demonstrating its practical application. The performance evaluation of DVAC indicates that the introduced overhead is within acceptable limits for practical usage scenarios. The rest of the paper is organized as follows. Section 2 introduces the background and related works. We present the system overview and threat model in Section 3, and detail the specific protocols and algorithms of DVAC in Section 4. Then, X. Xu et al.: Preprint submitted to Elsevier
2. Background and Related works
2.1. Distributed Version Control Systems DVCS improve project collaboration by providing participants with a complete repository and the ability to make local modifications. This flexibility empowers users to revise data locally, choose modifications to publish, and perform changes based on shared versions. In the absence of a central server, the project is redundantly stored across multiple participants, thereby eliminating single points of failure. Git, a widely used DVCS, stores a snapshot of each version (called commit) instead of just the differences between versions. Git comprises four primary components: workspace, stage, local repository, and remote repositories. Users manipulate files in the workspace, stage modifications using git add, create new versions with git commit, and share modifications by pushing to remote repositories with git push. GitHub serves as a popular remote repository. Users employ commands such as git clone or git fetch to obtain repositories, git branch to create or delete branches, git checkout to switch branches or restore files, and git merge to combine versions. These operations are executed using the Git client.
2.2. ABE and ABS ABE ensures that only entities with attributes satisfying a specified policy can successfully decrypt data [28]. Various ABE algorithms have been proposed, which can be classified into two categories: Key-Policy ABE (KP-ABE) and Ciphertext-Policy ABE (CP-ABE). In KP-ABE [17], access control policies are related to users’ secret keys. In CP-ABE [4], the user’s secret key is associated with their attributes, and the data owner specifies the access control policy in the ciphertext. The ciphertext can be decrypted by users whose attributes satisfy the specified policy. CP-ABE provides the data owner complete control over the data and is used in DVAC to enforce read access control. In recent years, a variety of CP-ABE algorithms [44, 18] adapted to practical scenarios have been proposed. CP-ABE1 consists of four functions: 𝐴𝐵𝐸.𝑆𝑒𝑡𝑢𝑝, 𝐴𝐵𝐸. 𝐾𝑒𝑦𝐺𝑒𝑛, 𝐴𝐵𝐸.𝐸𝑛𝑐𝑟𝑦𝑝𝑡 and 𝐴𝐵𝐸.𝐷𝑒𝑐𝑟𝑦𝑝𝑡. 1 Hereafter, ABE refers to CP-ABE for simplicity.
Page 2 of 14
Enforcing Cryptographic Distributed-VCS Access Control with No Trust on Servers
• 𝐴𝐵𝐸.𝑆𝑒𝑡𝑢𝑝(1𝜆 ): Takes a security parameter 1𝜆 as input and outputs a public parameter 𝑃 𝑃𝑟 and a master key 𝑀𝐾𝑟 . • 𝐴𝐵𝐸.𝐾𝑒𝑦𝐺𝑒𝑛(𝑀𝐾𝑟 , 𝑆𝑖 ): Takes the master key 𝑀𝐾𝑟 and an attribute set 𝑆𝑖 of user 𝑖 as input, and outputs a secret key 𝑆𝐾𝑟 . • 𝐴𝐵𝐸.𝐸𝑛𝑐𝑟𝑦𝑝𝑡(𝑃 𝑃𝑟 , 𝐴𝑃𝑟 , 𝑚): Takes the public parameter 𝑃 𝑃𝑟 , an access policy 𝐴𝑃𝑟 , and a message 𝑚 to be encrypted as input, and outputs the ciphertext 𝐶𝑚 . • 𝐴𝐵𝐸.𝐷𝑒𝑐𝑟𝑦𝑝𝑡(𝑃 𝑃𝑟 , 𝑆𝐾𝑟 , 𝐶𝑚 ): Takes the public parameter 𝑃 𝑃𝑟 , a secret key 𝑆𝐾𝑟 , and a ciphertext 𝐶𝑚 as input, and outputs the decrypted result 𝑚′ . ABS [24] ensures that only entities with attributes satisfying the specified access control policy can generate valid signatures. ABS consists of the following four algorithms. • 𝐴𝐵𝑆.𝑆𝑒𝑡𝑢𝑝(1𝜆 ): Takes a security parameter 1𝜆 and returns a public parameter 𝑃 𝑃𝑤 and a master key 𝑀𝐾𝑤 . • 𝐴𝐵𝑆.𝐾𝑒𝑦𝐺𝑒𝑛(𝑀𝐾𝑤 , 𝑆𝑖 ): Takes the master key 𝑀𝐾𝑤 and an attribute set𝑆𝑖 for user 𝑖 and returns a secret key 𝑆𝐾𝑤 . • 𝐴𝐵𝑆.𝑆𝑖𝑔𝑛(𝑃 𝑃𝑤 , 𝐴𝑃𝑤 , 𝑆𝐾𝑤 , 𝑚): Takes the public parameter 𝑃 𝑃𝑤 , an access policy 𝐴𝑃𝑤 , secret key 𝑆𝐾𝑤 and a message 𝑚, and returns a signature 𝜎. • 𝐴𝐵𝑆.𝑉 𝑒𝑟𝑖𝑓 𝑦(𝑃 𝑃𝑤 , 𝜎, 𝑚): Takes the public parameter 𝑃 𝑃𝑤 , a signature 𝜎 and a message 𝑚. Returns 1 if the signature is valid, otherwise returns 0.
2.3. Smart Contract Smart contracts, introduced by Nick Szabo in 1994, are “computerized transaction protocols that execute the terms of a contract” [8]. They aim to fulfill common contractual conditions (e.g., payment terms, liens) without the need for intermediaries [6]. Smart contracts are facilitated by blockchain platforms like Ethereum [39] and Hyperledger Fabric [13]. As a widely deployed blockchain, Ethereum enables developers to create smart contracts using languages like Solidity, compile them, and deploy them. The smart contracts are stored and executed on the Ethereum virtual machine. To deploy a smart contract, the owner initiates a transaction, creating a contract account. Any Ethereum account interacts with the smart contract through the contract account. When an Ethereum account invokes a function to update data stored on the Ethereum network, it submits a corresponding transaction, which is recorded on the Ethereum network.
2.4. Related Works In this section, we divide the work into three categories: centralized access control schemes, distributed access control schemes, and access control schemes for Git.
X. Xu et al.: Preprint submitted to Elsevier
Centralized access control schemes. In centralized access control schemes, a central server stores access controlrelated information (such as access control lists) and participates in the execution of controls. However, these schemes cannot scale to distributed scenarios because of the significant overhead imposed on access control enforcement entities. For example, in the scheme [35, 38] based on proxy re-encryption, the entity needs to perform independent re-encryption for each version and each delegated user. Similarly, in schemes based on selective encryption [37, 10], the entity needs to dynamically maintain the key derivation graph, which is not suitable for a larger number of cooperators. In contrast, DVAC only requires each entity to perform one ABE encryption and ABS signature for each version, regardless of the number of cooperators. Distributed access control schemes. Distributed access control schemes like ABE, ABS, and smart contracts have been used for fine-grained access control on distributed data. However, these schemes are not suitable for DVCS, as they either require a central server to assist and cannot meet the fully distributed requirements[27, 48, 22, 25], or they cannot provide write access control and do not support user collaboration[47, 30, 43, 21]. Both schemes [22, 25] propose access controls for electronic health records (EHR). RVWABE-CA [22] introduces a weighted attribute-based encryption scheme with revocation and verifiability, while CP-ABSC-MIoT [25] offers a privacypreserving access control scheme based on attribute signcryption. However, both focus solely on read permissions for EHR and omit write permission control. Additionally, both depend on a central Verification Server or Authorization Engine, limiting flexibility in distributed environments. Similarly, the schemes [27, 48] use ABE and ABS for data confidentiality and integrity, but also rely on a central server for revision checks. BaDS [47] uses smart contracts for access control in the Internet of Things (IoT), while Droplet [30] develops a decentralized authorization service for fine-grained access control. Exceline et al. [12] propose an EHR access control mechanism based on smart contracts, but the plaintext data remains unprotected during the smart contract-assisted operations. Yang et al.[43] introduce an attribute-based access control scheme for IoT using blockchain technology. Li et al.[21] present an efficient ciphertext-policy weighted attribute-based encryption scheme for multi-user collaborative access in cloud storage. However, these schemes mainly focus on confidentiality, lack support for write access control, and are not applicable to DVCS where read and write permissions are separate. Xu et al. [42] propose a simple distributed read/write framework, but metadata is protected only by digital signatures, requiring users to maintain the public key certificates of data owners. Additionally, the application and evaluation in real DVCS scenarios are not addressed. Access control schemes for Git. Several schemes have been proposed for securing Git. Gitolite [31] provides access control for Git in a central server model. Git-crypt [3] Page 3 of 14
Enforcing Cryptographic Distributed-VCS Access Control with No Trust on Servers
encrypts sensitive information in public repositories using Git filters [32]. Git-remote-gcrypt [5] encrypts entire repositories, distributing decryption keys through GPG. GitHub Enterprise [11] provide access control services based on the role-based access control (RBAC) model. Keybase-git [20] is built on the Keybase Encrypted File System (KBFS), and uses the ACL model for access control. In 2023, Xu et al. proposed Gringotts [41], an end-to-end encrypted VCS with file-level read access control using ABE and branch-level write access control using ECDSA. However, Gringotts relies on a remote server for maintaining an encrypted shadow repository and lacks flexibility in DVCS scenarios. DVAC integrates with Git through Git filters, providing fine-grained protection for each file in the repository. Key management in DVAC is greatly simplified because users only need to maintain their own read and write attribute keys, and data owners only need to set access policies based on attributes, without managing other users’ related data.
3. System Overview For DVCS with distributed data storage, determining how to enforce and maintain consistent access control for distributed nodes is one of the most important challenges. The access control scheme should not require the participation of the central server, forcing the protection of file data on each distributed node, and the current access control scheme requires the participation of the server, which is easily bypassed by the node in DVCS.
In distributed version control scenarios, DVAC is designed to eliminate the user’s reliance on a central server while ensuring accurate fine-grained read/write access control. Based on this premise, our objective is to minimize alterations and impact to existing DVCS and achieve seamless integration and user-friendliness of DVAC without requiring data migration or changes to normal operations. With these design goals in mind, we present a system overview of DVAC in this section. As shown in Figure 1, DVAC comprises three modules: enforcing cryptographic access control (EAC), version control adaptation (VCA) and trusted metadata management (TMM). DVAC involves the smart contract deployed on the blockchain, distributed user repositories and attribute authorities. Attribute authorities are responsible for user registration, key distribution and maintenance (such as 𝑃 𝑃 ), and are associated with the initial deployment of DVAC, which is not detailed here. The smart contract is deployed on the blockchain and is responsible for managing and maintaining the metadata version to ensure its correctness and validity. Users have a complete repository on their local storage, which is a distributed node in the DVCS. Following local modifications, users can opt to push them to other repositories. Users possess varying permissions for different files, categorized as data owners and readers/writers. Data owners have full control over the files they create and can specify and modify access policies, while readers/writers need to choose to read or modify data according to their own permissions.
Table 1 Symbol table.
Enforcing Cryptographic Access Control Metadata
Local Repo
Smart Contract
Symbol 𝑆𝐾𝑖𝑟 𝑆𝐾𝑖𝑤 𝐼𝐷𝑓 𝐼𝐷𝑜 𝐴𝑃𝑓𝑟 𝐴𝑃𝑓𝑤 𝑀𝑒𝑡𝑎𝑓 𝐶𝑖𝑝ℎ𝑒𝑟𝑓 𝑆𝑖𝑔𝑓 List𝑢 List𝑓 List𝐴𝑃
Description The read key of user 𝑖, used for ABE.Dec. The write key of user 𝑖, used for ABS.Sign. The unique identifier of the file. The unique identifier of a data owner. Read access policy for file 𝑓 . Write access policy for file 𝑓 . Metadata for file 𝑓 . Ciphertext of the file 𝑓 content. ABS signature of the file 𝑓 . The collection of mappings between 𝐼𝐷𝑜 s and blockchain accounts. The collection of all 𝐼𝐷𝑓 s created. The collection of all metadata (including historical versions) indexed by 𝐼𝐷𝑓 s.
We summarized the following three difficulties: 1. Enforce cryptographic access control across all DVCS nodes and separately control read and write permissions; 2. Access control must be fully compatible with DVCS features such as version control; 3. Access control-related data (such as access policies) requires distributed and secure storage and trusted management to provide consistent access control across multiple nodes. X. Xu et al.: Preprint submitted to Elsevier
Create
Data Owner
Metadata Access Policy
V0
add + commit ABE.Enc+ABS.Sig Plaintext
Query
Writer1
Metadata Access Policy
add + commit ABE.Enc+ABS.Sig
V1'
push
Ciphertext Signature
Plaintext
V1''
Query
Writer2
push Reader
Metadata Access Policy
checkout ABS.Ver+ABE.Dec
clone/fetch Ciphertext Signature
Plaintext
Trusted Metadata Management
push
Ciphertext Signature
V1
diff/merge ABS.Ver+ABE.Dec
V1'
clone/fetch
V1'' conflict
Version Control Adaptation
Figure 1: The architecture of DVAC.
The EAC module is responsible for providing enforcement and consistent access control for files stored in distributed user repositories within DVCS. It also safeguards the historical versions of files stored in the user’s local repository, which contain file ciphertexts and signatures. Ensuring that the original DVCS version control function is not affected when the files in the repository are all ciphertext is a crucial problem to address. We designed the VCA module to ensure the accuracy of DVCS version control of encrypted files. When users execute version control Page 4 of 14
Enforcing Cryptographic Distributed-VCS Access Control with No Trust on Servers
commands, appropriate data conversion and adjustment are performed to ensure the accurate execution of commands. The TMM module is essential for ensuring proper access control. It manages versions of metadata (including access policies) and maintains metadata security. The attribute authority is responsible for distributing attribute keys to users. As shown in Figure 1, the data owner creates a plaintext file 𝑉 0, encrypts and signs it according to the access policy, and stores it in the local repository. In this case of cryptographic protection, the file can be shared with other users, who can then perform access control operations based on access policies and their own attribute keys. The metadata containing the access policy is managed by the smart contract, and users have the capability to request metadata from the smart contract at any time during access control operations. Suppose that two modifiers create the 𝑉 1 version of a file at the same time, which is called 𝑉 1′ and 𝑉 1′′ . This will cause version conflicts and require version control operations such as merging and comparing. DVAC will retrieve files in plaintext via the version control adaptation module for further DVCS operations. Threat Model. In DVAC, each 𝐴𝐴 is trusted and securely stores sensitive information, such as 𝑀𝐾𝑟 , 𝑀𝐾𝑤 , and user secret keys. 𝐴𝐴 authenticates users and verifies their attributes before generating their keys. Public repositories hosting the data are honest-but-curious, storing all versions correctly but potentially performing unauthorized read or write operations. Valid users verify received versions using ABS signatures, decrypt data with their secret keys (𝑆𝐾𝑟𝑖 ), and generate valid ABS signatures for modified data using 𝑖 ). Malicious users may engage in unautheir secret keys (𝑆𝐾𝑤 thorized activities, such as attempting to infer unauthorized data, uploading invalid modifications, or launching DDoS attacks. Collusion among malicious users is also possible to gain additional privileges.
4. DVAC Scheme Design This section provides a detailed introduction to the specific design and protocol process of DVAC, along with proposed mitigation ideas for the challenging problems raised in the previous section. Before delving into the specific protocols of DVAC, we establish the symbolic representation of the basic cryptographic algorithms as follows: • 𝐶 ← 𝐸𝑛𝑐(𝑀, 𝑘): Use the key 𝑘 to perform symmetric encryption (e.g., AES) on the plaintext 𝑀 to obtain the ciphertext 𝐶. • 𝑀 ← 𝐷𝑒𝑐(𝐶, 𝑘): Use the key 𝑘 to perform symmetric decryption on the ciphertext 𝐶 to obtain the plaintext 𝑀. • 𝑠 ← 𝑆𝑖𝑔(𝑀, 𝑠𝑘): Asymmetric cryptographic algorithm (such as RSA). Use the private key 𝑠𝑘 to sign the message 𝑀 to obtain the signature 𝑠.
X. Xu et al.: Preprint submitted to Elsevier
• 0∕1 ← 𝑉 𝑒𝑟𝑖𝑓 𝑦(𝑠, 𝑀, 𝑝𝑘): Use the public key 𝑝𝑘 to verify the signature 𝑠, output 1 means the signature is valid, otherwise it is invalid.
4.1. Initialization Phase During the initialization phase of DVAC, the 𝐴𝐵𝐸.𝑆𝑒𝑡𝑢𝑝 and 𝐴𝐵𝑆.𝑆𝑒𝑡𝑢𝑝 procedures are initially performed by the attribute authority to generate the associated public parameters (𝑃 𝑃𝑟 , 𝑃 𝑃𝑤 ) and master keys (𝑀𝐾𝑟 , 𝑀𝐾𝑤 ), which is followed by the user registration process. Each user needs to register with a trusted authority to obtain an authenticated identity ID. The protocol of register is as follows: In real-world application scenarios, there are typically one or more trusted institutions responsible for verifying the user’s actual identity in order for the user to register an account. The trusted institution provides the user with a DVCS account containing a verifiable ID. 1. The trusted institution generates a pair of signature keys (𝑠𝑘𝑎 , 𝑝𝑘𝑎 ); 2. Authenticate the user 𝐼𝐷 and generate a pair of signature keys (𝑠𝑘𝐼𝐷 , 𝑝𝑘𝐼𝐷 ) for the user; 3. Distribute (𝑠𝑘𝐼𝐷 , 𝑐𝑒𝑟𝑡) for the registered user 𝐼𝐷, where 𝑐𝑒𝑟𝑡 = (𝐼𝑛𝑓 𝑜𝐼𝐷 , 𝑠) = ((𝐼𝐷, 𝑝𝑘𝐼𝐷 ), 𝑠), 𝑠 = 𝑆𝑖𝑔(𝐼𝑛𝑓 𝑜𝐼𝐷 , 𝑠𝑘𝑎 ). In DVAC, users collaborate securely in DVCS with the help of blockchain. As a result, users go through the registration process using the blockchain smart contract. 1. The user 𝐼𝐷 creates a blockchain account 𝐴𝑐𝑐; 2. The user 𝐼𝐷 initiates a registration request 𝑅𝑒𝑞(𝑟𝑒𝑔, 𝐴𝑐𝑐, 𝐼𝐷, 𝑐𝑒𝑟𝑡, 𝑠′ ) to the smart contract, where 𝑠′ = 𝑆𝑖𝑔(𝐴𝑐𝑐|𝑐𝑒𝑟𝑡, 𝑠𝑘𝐼𝐷 ). 3. The smart contract verifies 𝑠, 0∕1 ← 𝑉 𝑒𝑟𝑖𝑓 𝑦(𝑠, 𝐼𝑛𝑓 𝑜𝐼𝐷 , 𝑝𝑘𝑎 ). If 0 is returned, the error code “cert error” is printed. 4. The smart contract verifies 𝑠′ , 0∕1 ← 𝑉 𝑒𝑟𝑖𝑓 𝑦(𝑠′ , 𝐴𝑐𝑐|𝑐𝑒𝑟𝑡, 𝑝𝑘𝐼𝐷 ). If 0 is returned, the error code “user error” is printed. 5. The smart contract adds (𝐴𝑐𝑐, 𝐼𝐷) → 𝐿𝑖𝑠𝑡𝑢 . In DVCS, the data are stored in the form of files, and DVAC adds extra information for each file to enforce the access control. Firstly, we introduce file-related data structures designed in DVAC. • File ID: The identity of each file (𝑓 ) need to be unique and easily derivable for users. In DVAC, the file ID 𝐼𝐷𝑓 is defined as 𝐼𝐷𝑓 = (𝐼𝑛𝑖𝑡_𝐶𝐼𝐷|𝑅_𝑁𝑎𝑚𝑒| 𝐹 _𝑃 𝑎𝑡ℎ), where 𝐼𝑛𝑖𝑡_𝐶𝐼𝐷 is the digest of the first commit information (e.g., creator, creating time, included files, etc.) of the repository, and 𝐹 _𝑃 𝑎𝑡ℎ is the relative file path. 𝐼𝑛𝑖𝑡_𝐶𝐼𝐷 and 𝑅_𝑁𝑎𝑚𝑒 can uniquely refer to a repository, and 𝐹 _𝑃 𝑎𝑡ℎ can uniquely specify a file in the repository. • Metadata: Metadata refers to information about file and access policies. We define the metadata of a file as Page 5 of 14
Enforcing Cryptographic Distributed-VCS Access Control with No Trust on Servers
𝑀𝑒𝑡𝑎𝑓 is 𝑀𝑒𝑡𝑎𝑓 = (𝐼𝐷𝑜 , 𝐼𝐷𝑓 , 𝐴𝑃𝑟𝑓 , 𝐴𝑃𝑤𝑓 ), where 𝐼𝐷𝑜 and 𝐼𝐷𝑓 are the unique identity of the data owner and the file, and 𝐴𝑃𝑟𝑓 and 𝐴𝑃𝑤𝑓 are the read and write access policies of the file, respectively. 𝑀𝑒𝑡𝑎𝑓 is indexed by 𝐼𝐷𝑓 , bound to file (𝑓 ) one by one, and the rest part 𝐼𝐷𝑜 , 𝐼𝐷𝑓 , 𝐴𝑃𝑟𝑓 and 𝐴𝑃𝑤𝑓 can only be modified by the data owner 𝐼𝐷𝑜 .
Enforcing Cryptographic Access Control Protocol-Creation Blockchain
Data Owner
Smart contract
DVAC
DVCS Set ID f ACr , ACw
• File: In DVAC, each file (𝑓 ) is stored in the form of [𝑀𝑒𝑡𝑎𝑓 , 𝐶𝑖𝑝ℎ𝑒𝑟𝑓 , 𝑆𝑖𝑔𝑓 ], where 𝐶𝑖𝑝ℎ𝑒𝑟𝑓 contains the ciphertext of 𝑓 , while 𝑆𝑖𝑔𝑓 is the ABS signature of 𝐶𝑖𝑝ℎ𝑒𝑟𝑓 .
Create metadata [ ID f , ID o , ACr , ACw ] Create
Create success
Here, we establish a unique and easily generated 𝐼𝐷𝑓
for each file to ensure that the user can accurately index the metadata using the 𝐼𝐷𝑓 , thereby avoiding confusion resulting from ID duplication and data owner preemption.
Create plaintext
In DVAC, users only need to possess their own pair of read and write attribute keys for file-level access control in various repositories. This reduces the burden of key management for users. In DVCS environments, files resemble blockchain ledgers and can be stored in a distributed manner in local repositories of each participating user. Users who are unable to decrypt files using the read attribute key do not have read access, and similarly, users who are unable to generate valid signatures using the write attribute key do not have write access. We describe the EAC module in detail below, including EAC protocols and adjustments to basic DVCS file operations. As shown in Figure 2, when creating a file, the data owner needs to set the read and write access policies (𝐴𝑃𝑟 , 𝐴𝑃𝑤 ) for the file. DVAC will generate the file ID 𝐼𝐷𝑓 and synthesize the metadata (𝐼𝐷𝑜 , 𝐼𝐷𝑓 , 𝐴𝑃𝑟𝑓 , 𝐴𝑃𝑤𝑓 ) to initiate a metadata creation request to the smart contract. The metadata creation process can be synchronized with the process of the data owner writing the contents of the file. Upon completion of both processes, DVAC performs 𝐴𝐵𝐸.𝐸𝑛𝑐 and 𝐴𝐵𝑆.𝑆𝑖𝑔𝑛 according to the read and write access policy and the attribute key(𝑆𝐾𝑟 , 𝑆𝐾𝑤 ), and stores the generated [𝐶𝑖𝑝ℎ𝑒𝑟, 𝑆𝑖𝑔] in the local repository of the data owner. The data owner has the option to share the file [𝐶𝑖𝑝ℎ𝑒𝑟, 𝑆𝑖𝑔] with other users. Then, we show how to enforce the read-write file protocol on a distributed client as shown in Figure 3. Suppose that the client stores three versions of the file (𝑉0 , 𝑉1 , 𝑉2 ), and the file content is in the form of [𝐶𝑖𝑝ℎ𝑒𝑟, 𝑆𝑖𝑔]. To read file 𝑉2 , DVAC obtains the 𝐼𝐷𝑓 and queries the metadata of the corresponding version from the smart contract. After obtaining the metadata, DVAC first verifies the signature 𝑆𝑖𝑔2 according to the write access policy 𝐴𝑃𝑤 . If the verification is successful, 𝑈 𝑠𝑒𝑟2 has the write permission and the file version 𝑉2 is valid. Next, DVAC will decrypt 𝐶𝑖𝑝ℎ𝑒𝑟2 according to 𝐴𝑃𝑟 and the user’s attribute key. If the user’s attributes meet X. Xu et al.: Preprint submitted to Elsevier
Other users’repo
ABE.Enc ABS.Sig
4.2. Enforcing Cryptographic Access Control (EAC)
Save File
[Cipher , Sig ] Save File V0
[Cipher , Sig ]
Share File V0
[Cipher , Sig ]
Figure 2: Enforcing cryptographic access control protocol with file creation.
the access policy 𝐴𝑃𝑟 , the decryption is successful, and the plaintext file will be displayed in the client workspace. If the signature is invalid, 𝑈 𝑠𝑒𝑟2 does not have write permission. DVAC will return an error warning and choose to verify the latest historical version 𝑉1 according to user requirements until a valid version is verified. If decryption fails, DVAC returns an error warning indicating no permissions. When a user modifies a file and intends to store it as a new version, DVAC encrypts the file according to the access policy and public parameter, and signs the ciphertext with the user’s attribute key 𝑆𝐾𝑤 , obtaining [𝐶𝑖𝑝ℎ𝑒𝑟3 , 𝑆𝑖𝑔3 ]. The user’s local repository stores the 𝑉3 version of the file, and can share it with other users. The EAC protocol ensures that access control can be distributed on user nodes without the involvement of a central server, enforcing cryptographic protection. The data obtained from other nodes is in the form of [𝐶𝑖𝑝ℎ𝑒𝑟, 𝑆𝑖𝑔]. The plaintext data can be read only after being verified and decrypted by the user. Unauthorized modification can only affect the local repository of the modifier and cannot be accepted by other users.
4.3. Version Control Adaptation (VCA) DVAC ensures that files in the user repository are encrypted. Users need to verify and decrypt [𝐶𝑖𝑝ℎ𝑒𝑟, 𝑆𝑖𝑔] to obtain plaintext data. Each file version is encrypted with a distinct key, resulting in a different ciphertext. The version 3 𝑉 is created by the data owner. Assume that 𝑉 is the version modified 0 1 by 𝑈 𝑠𝑒𝑟1 and 𝑉2 is the version modified by 𝑈 𝑠𝑒𝑟2 .
Page 6 of 14
Enforcing Cryptographic Distributed-VCS Access Control with No Trust on Servers Enforcing Cryptographic Access Control Protocol-Modification Blockchain
User
Save File ID f
Version Control Adaptation Protocol
Smart contract
DVAC
DVCS
diff/merge operation, and the final result is displayed in the workspace.
User
Obtain f
V0 : [Cipher0 , Sig 0 ] V1 : [Cipher1 , Sig1 ] V2 : [Cipher2 , Sig2 ]
ID
Query metadata [ ID f ,V2 ] Query
Metadata [ ID f , ID o , ACr , ACw ]
Blockchain DVAC
DVCS Save File IDf V0:[Cipher0,Sig0] V1:[Cipher1,Sig1] V2:[Cipher2,Sig2]
diff/merge V1 V2
f
Read ID V2
File IDf V1、V2
ABS.Verify
Sig 2
1:vaild 0:error Reject V2
Repeat
f
o
Query metadata [IDf],V1,V2
Query
Metadata [ ID , ID , ACr , ACw ]
ABS.Verify
Sig1
Obtain IDf
f
Query metadata [ ID ,V1 ]
Query
1:vaild 0:error
Metadata [Cipher1,Sig1] [Cipher2,Sig2]
ABE.Dec Cipher2
0:error No access
Signatuer invalid
V1[IDf, IDo, ACr, ACw] V2[IDf, IDo, AC’r, AC’w]
ABS.Verify
plaintext
Reject error version Abort
Modify
ABE.Dec No Access
Other users’repo ABE.Enc ABS.Sig
Abort V1:plaintext V2:plaintext
Save File [Cipher3 , Sig3 ] diff/merge
Save File V3
[Cipher3 , Sig 3 ]
update File V3 [Cipher3 , Sig 3 ]
Figure 4: Version control adaptation protocol. Figure 3: Enforcing cryptographic access control protocol with other file operations.3
control function of DVCS, encompassing the maintenance, merging, and comparison of different versions, does not directly address the management of ciphertext. Consequently, we have developed an adaptation protocol for version control. DVAC needs to release the cryptographic protection of related files when users execute version control commands and display the plaintext result of the command execution in the workspace. Meanwhile, the files in the repository remain encrypted. As shown in Figure 4, the user’s local repository stores three versions of file 𝐼𝐷𝑓 . The user initiates the diff/merge command for 𝑉1 and 𝑉2 in the workspace. Subsequently, DVAC sends a metadata query request to the smart contract with 𝐼𝐷𝑓 , 𝑉1 , and 𝑉2 as additional information. Upon receiving the metadata corresponding to the two versions from the smart contract, DVAC retrieves [𝐶𝑖𝑝ℎ𝑒𝑟1 , 𝑆𝑖𝑔1 ] and [𝐶𝑖𝑝ℎ𝑒𝑟2 , 𝑆𝑖𝑔2 ] from the user repository, verifying and decrypting the files individually. In the event of a verification or decryption failure, a warning message is sent to the user workspace. DVAC then forwards the successful plaintext of 𝑉1 and 𝑉2 to the DVCS for automatic X. Xu et al.: Preprint submitted to Elsevier
4.4. Trusted Metadata Management (TMM) As described in Section 4.1, DVAC metadata contains information about files, as well as read and write access policies. The metadata is mapped to a file using a unique 𝐼𝐷𝑓 . Different versions of the file may correspond to different versions of the metadata. The security of metadata determines the effectiveness of access control. However, current DVCS lack a proper mechanism to store and maintain DVAC-related metadata for each file version. Once the maintenance of metadata has security vulnerabilities, it will pose additional risks to the security of DVCS data. In a distributed scenario, if metadata is stored in DVCS in the same form as normal files, users cannot build a global view of the repository and are vulnerable to metadata replay attacks. The attacker may attempt to obtain revoked permissions, by replaying old metadata in which his permissions are not revoked. The victim, who has not received the latest version of the data, may accept this metadata and the attacker’s revisions. Due to the inability of users to have a comprehensive overview of all file metadata, obtaining the required correct version of metadata independently is Page 7 of 14
Enforcing Cryptographic Distributed-VCS Access Control with No Trust on Servers
challenging. Additionally, metadata relies on 𝐼𝐷𝑓 for file mapping and 𝐼𝐷𝑜 for determining the data owner. Attackers may create a large number of files in advance and delete them to preempt data owner attacks. Even if the 𝐼𝐷𝑓 is uniquely generated, there is no way to avoid the extreme situation where two data owners create files with the same name and the same path in one repository, leading to the problem of confusing the ownership of the data. The fundamental cause of these attacks is the inability of the data owner and user to build a global view of the repository to check if 𝐼𝐷𝑓 has been allocated and obtain the corresponding valid metadata. However, building a global view will introduce the significant performance overhead, which becomes an obstacle in applying DVAC in the practical DVCS. In order to solve the above problem, we have devised a blockchain-based mechanism for maintaining metadata, ensuring distributed and trustworthy management for DVACrelated metadata. The characteristics of blockchain, such as addition-only, immutability, and distributed ledger, are highly suitable for fully distributed environments. By leveraging smart contracts, we have developed a distributed and trusted mechanism for managing metadata. As shown in Figure 5, the TMM mechanism encompasses four algorithms: metadata creation, metadata modification, owner information replacement, and metadata querying. Users are required to submit a request 𝑅𝑒𝑞(𝑓 𝑢𝑛𝑐𝑡𝑖𝑜𝑛, … ) to the smart contract, with the first parameter specifying the action the smart contract should undertake (register, create, modify, replace or query). The smart contract includes two fundamental functions: 𝐸𝑥𝑖𝑠𝑡(𝑎, 𝐿𝑖𝑠𝑡) to check if 𝑎 exists in 𝐿𝑖𝑠𝑡, and 𝐺𝑒𝑡(𝑎, 𝐿𝑖𝑠𝑡) to obtain an item based on the index of 𝑎 in 𝐿𝑖𝑠𝑡. The creation 𝑀𝑑_𝐶𝑟𝑒𝑎𝑡𝑒() and modification 𝑀𝑑_𝑀𝑜𝑑𝑖𝑓 𝑦() of metadata necessitate the smart contract to validate the 𝐼𝐷𝑜 and the correctness of the account binding before appending the new metadata to 𝐿𝑖𝑠𝑡𝐴𝑃 , as shown in Figure 5. The distinction lies in the fact that metadata creation requires the retrieval of 𝐿𝑖𝑠𝑡𝑓 to ensure that the 𝐼𝐷𝑓 is unused, thus avoiding metadata conflicts and resisting metadata preemption attacks. Owner information replacement 𝑀𝑑_𝑅𝑒𝑝𝑙𝑎𝑐𝑒() is divided into 𝐼𝐷𝑜 replacement and bound account 𝐴𝑐𝑐 𝑜 replacement, denoted by a 𝑡𝑎𝑔. Metadata querying 𝑀𝑑_𝑄𝑢𝑒𝑟𝑦() does not mandate authentication of the requester’s identity, and the smart contract only indexes and outputs the metadata based on 𝐼𝐷𝑓 and version 𝑣.
5. Disac Applied in Git DVAC can be readily applied in DVCS. In this context, we use the widely adopted DVCS, Git, as an example to illustrate the practical integration process. We introduce the integration of DVAC in Git and elucidate the specific process for users utilizing Git. For Git integration, we have implemented a Git filter driver, and associated it with a long-running filter [15] for a specified subset of files by configuring Git attributes for the repository. The long-running filter, supported since Git 2.11, X. Xu et al.: Preprint submitted to Elsevier
Metadata Management 𝑀𝑒𝑡𝑎𝑓 ← 𝑀𝑑_𝐶𝑟𝑒𝑎𝑡𝑒(𝐼𝐷𝑜 , 𝐼𝐷𝑓 , 𝐴𝑃𝑟𝑓 , 𝐴𝑃𝑤𝑓 , 𝐴𝑐𝑐 ′ ): 1. Query 𝐼𝐷𝑜 , (𝐴𝑐𝑐 𝑜 , 𝐼𝐷𝑜 ) ← 𝐺𝑒𝑡(𝐼𝐷𝑜 , 𝐿𝑖𝑠𝑡𝑢 ); 2. If 𝐴𝑐𝑐 ′ = 𝐴𝑐𝑐 𝑜 , continue, otherwise output "error 1"; 3. Query 𝐼𝐷𝑓 , 0∕1 ← 𝐸𝑥𝑖𝑠𝑡(𝐼𝐷𝑓 , 𝐿𝑖𝑠𝑡𝑓 ). If 0 is returned, output "error 2". If 1 is returned, 𝐼𝐷𝑓 → 𝐿𝑖𝑠𝑡𝑓 . 4. (𝐼𝐷𝑓 , 𝐼𝐷𝑜 , 𝐴𝑃𝑟𝑓 , 𝐴𝑃𝑤𝑓 ) → 𝐿𝑖𝑠𝑡𝐴𝑃 , output 𝑀𝑒𝑡𝑎𝑓 = (𝐼𝐷𝑓 , 𝐼𝐷𝑜 , 𝐴𝑃𝑟𝑓 , 𝐴𝑃𝑤𝑓 ). 𝑀𝑒𝑡𝑎𝑓 ← 𝑀𝑑_𝑀𝑜𝑑𝑖𝑓 𝑦(𝐼𝐷𝑜 , 𝐼𝐷𝑓 , 𝐴𝑃𝑟𝑓 , 𝐴𝑃𝑤𝑓 , 𝑣, 𝐴𝑐𝑐 ′ ): 1. Query 𝐼𝐷𝑜 , (𝐴𝑐𝑐 𝑜 , 𝐼𝐷𝑜 ) ← 𝐺𝑒𝑡(𝐼𝐷𝑜 , 𝐿𝑖𝑠𝑡𝑢 ); 2. If 𝐴𝑐𝑐 ′ = 𝐴𝑐𝑐 𝑜 , continue, otherwise output "error 1"; 3. Obtain 𝑀𝑒𝑡𝑎𝑓 of version 𝑣, 𝑀𝑒𝑡𝑎𝑓 ← 𝐺𝑒𝑡(𝐼𝐷𝑓 , 𝐿𝑖𝑠𝑡𝐴𝑃 , 𝑣); 4. 𝐴𝑃𝑟𝑓 , 𝐴𝑃𝑤𝑓 → 𝑀𝑒𝑡𝑎𝑓 , output new 𝑀𝑒𝑡𝑎𝑓 . ′
′
𝑀𝑒𝑡𝑎𝑓 ← 𝑀𝑑_𝑅𝑒𝑝𝑙𝑎𝑐𝑒(𝐼𝐷𝑓 , 𝐼𝐷𝑜 , 𝐼𝐷𝑜 ∕𝐴𝑐𝑐 𝑜 , 𝑡𝑎𝑔): 1. Query 𝐼𝐷𝑜 , (𝐴𝑐𝑐 𝑜 , 𝐼𝐷𝑜 ) ← 𝐺𝑒𝑡(𝐼𝐷𝑜 , 𝐿𝑖𝑠𝑡𝑢 ) 2. If 𝐴𝑐𝑐 ′ = 𝐴𝑐𝑐 𝑜 , continue, otherwise output "error1"; ′ 3. 𝑡𝑎𝑔 = 1: (𝐴𝑐𝑐 𝑜 , 𝐼𝐷𝑜 ) → 𝐿𝑖𝑠𝑡𝑢 4. 𝑡𝑎𝑔 = 2: 1) Obtain 𝑀𝑒𝑡𝑎𝐼𝐷𝑓 of version 𝑣, 𝑀𝑒𝑡𝑎𝑓 ← 𝐺𝑒𝑡(𝐼𝐷𝑓 , 𝐿𝑖𝑠𝑡𝐴𝑃 , 𝑣); ′ 2) 𝐼𝐷𝑜 → 𝑀𝑒𝑡𝑎𝑓 . 𝑀𝑒𝑡𝑎𝑓 ← 𝑀𝑑_𝑄𝑢𝑒𝑟𝑦(𝐼𝐷𝑓 , 𝑣) ∶ 1. Obtain 𝑀𝑒𝑡𝑎𝑓 of version 𝑣, 𝑀𝑒𝑡𝑎𝐼𝐷𝑓 ← 𝐺𝑒𝑡(𝐼𝐷𝑓 , 𝐿𝑖𝑠𝑡𝐴𝑃 , 𝑣); 2. Output 𝑀𝑒𝑡𝑎𝑓 .
Figure 5: Metadata management algorithms
transmits the file path and content to the driver, and allows a long-running process to operate multiple files instead of only one in the previous version of Git filter. The registered filter driver includes the processes for two commands: clean and smudge. • The clean command is invoked when a user’s modification is added from the workspace to the stage through git add. In DVAC, as shown in Figure 6, the process for clean command initially computes the 𝐼𝐷𝑓 , retrieves the metadata of 𝐼𝐷𝑓 by querying the smart contract, performs 𝐴𝐵𝐸.𝐸𝑛𝑐 and 𝐴𝐵𝑆.𝑆𝑖𝑔𝑛 with 𝐴𝑃𝑟 and 𝐴𝑃𝑤 , and ultimately returns the ciphertext and signature to the Git client for storage in the stage. • The smudge command is invoked when a user pulls the revisions from the remote/local repository or stage to the workspace through the commands such as git pull and git checkout. In DVAC, as shown in Figure 6, the Page 8 of 14
Enforcing Cryptographic Distributed-VCS Access Control with No Trust on Servers
process for the smudge command derives 𝐼𝐷𝑓 , queries the smart contract for the latest metadata, verifies the ABS signature with 𝐴𝑃𝑤 , obtains the plaintext after performing ABE decryption with 𝐴𝑃𝑟 , and finally returns the plaintext file to the workspace. Blockchain
metadata
git add
Theorem 2. DVAC is resistant to data owner preemption and impersonation attacks targeting metadata. metadata
Workspace
Filter
Stage
plaintext file
clean ABE.Encrypt ABS.Sign
Ciphertext Signature
smudge ABS.Verify ABE.Decrypt
Ciphertext Signature
git checkout plaintext file
forged signature. Other users obtain the correct 𝐴𝑃𝑤 through the smart contract after obtaining the file 𝑓 ′ , and return 0 after executing 𝐴𝐵𝑆.𝑉 𝑒𝑟𝑖𝑓 𝑦(𝑆𝑖𝑔𝑓 ′ ,𝐴𝑃𝑤 ). Therefore, all users who execute DVAC correctly will not accept the file 𝑓 ′ , meaning that the modifications made by unauthorized write user 𝐵 are invalid.
Figure 6: DVAC design integrated with Git.
We have developed a web interface based on web3.js [34] for the data owner to manage the metadata. This includes the 𝑀𝑑_𝐶𝑟𝑒𝑎𝑡𝑒 function for establishing the initial access control policy for a new 𝐼𝐷𝑓 , the 𝑀𝑑_𝑀𝑜𝑑𝑖𝑓 𝑦 function for altering the access control policy, the 𝑀𝑑_𝑅𝑒𝑝𝑙𝑎𝑐𝑒 function for transferring ownership and the account, and the 𝑀𝑑_𝑄𝑢𝑒𝑟𝑦 function for retrieving the correct metadata. For users, the data exists in plaintext in the workspace, and the VCA protocol ensures that standard Git operations (such as git merge or conflict resolution) remain unaffected. For the git rm operation, instead of deleting the file, DVAC clears the file content and stores the ABS signature (including the parameters) of the git rm operation in the file, which allows other users to calculate 𝐼𝐷𝑓 and check the write permission. The encrypted and signed contents of the file are ultimately stored in the .∕𝑜𝑏𝑗𝑒𝑐𝑡𝑠 folder of the repository.
6. Security Analysis In this section, we present a concise security analysis of DVAC. Theorem 1. DVAC provides file granularity, read permission security for unauthorized read users and write permission security for unauthorized write users. Proof. In a file 𝑓 [𝑀𝑒𝑡𝑎𝑓 , 𝐶𝑖𝑝ℎ𝑒𝑟𝑓 , 𝑆𝑖𝑔𝑓 ], the attribute set 𝑆𝑎 of unauthorized read user 𝐴 does not meet 𝐴𝑃𝑟 , and the attribute set 𝑆𝑏 of unauthorized write user 𝐵 does not meet 𝐴𝑃𝑤 . After obtaining 𝐶𝑖𝑝ℎ𝑒𝑟𝑓 , user 𝐴 needs to decrypt the 𝐶𝑖𝑝ℎ𝑒𝑟𝑓 to obtain the plaintext. Because 𝑆𝑎 does not satisfy 𝐴𝑃𝑟 and returns an error when executing 𝐴𝐵𝐸.𝐷𝑒𝑐, plaintext cannot be obtained by user 𝐴. User 𝐵 reads file 𝑓 and makes modifications to obtain file 𝑓 ′ . When 𝐴𝐵𝑆.𝑆𝑖𝑔𝑛 is executed based on 𝐴𝑃𝑤 in 𝑀𝑒𝑡𝑎𝑓 , an error is returned because 𝑆𝑏 does not meet 𝐴𝑃𝑤 , and the correct signature cannot be obtained. However, file 𝑓 ′ [𝐶𝑖𝑝ℎ𝑒𝑟𝑓 ′ , 𝑆𝑖𝑔𝑓 ′ ] is generated if user 𝐵 chooses a forged (𝑆𝑏 satisfied) 𝐴𝑃𝑤′ to sign, or a X. Xu et al.: Preprint submitted to Elsevier
Proof. Against the two types of attacks: • For the data owner preemption attack, the attacker will create a large number of file metadata in advance to overwrite the 𝐼𝐷𝑓 that may be used to become the corresponding data owner in advance. In DVAC, the creation of metadata must make a 𝑅𝑒𝑞(𝑐𝑟𝑒𝑎𝑡𝑒) to the smart contract. In the process of calling 𝑀𝑑_𝐶𝑟𝑒𝑎𝑡𝑒, it is necessary to determine whether the created 𝐼𝐷𝑓 has been recorded in the 𝐿𝑖𝑠𝑡𝑓 . Thus, the uniqueness check in 𝑀𝑑_𝐶𝑟𝑒𝑎𝑡𝑒 ensures that the invoker will select a globally unique and unused 𝐼𝐷𝑓 , making preemption of 𝐼𝐷𝑓 impossible. In addition, metadata creation requires a transaction to be initiated and costs a certain amount of ETH, introducing the significant overhead for the attackers attempting frequent invocations to preempt a larger number of 𝐼𝐷𝑓 . • For a data owner impersonation attack, an attacker may modify the 𝐼𝐷𝑜 in the metadata with 𝑀𝑑_𝑅𝑒𝑝𝑙𝑎𝑐𝑒, or by directly tampering with the blockchain. For 𝑀𝑑_𝑅𝑒𝑝𝑙𝑎𝑐𝑒, as long as the user’s private key remains secure, the attacker cannot forge a valid signature to impersonate the victim, and therefore the consistency check of the invoker’s identifier and stored 𝐼𝐷𝑜 in 𝑀𝑑_𝑅𝑒𝑝𝑙𝑎𝑐𝑒 prevents the attacker from successfully invoking 𝑀𝑑_𝑅𝑒𝑝𝑙𝑎𝑐𝑒. Direct tampering on the blockchain is prevented by the tamper-resistant feature of the smart contract (with the underlying blockchain). Therefore, DVAC can resist data owner preemption and impersonation attacks targeting metadata. Theorem 3. DVAC can protect metadata from tampering and resist metadata replay attacks. Proof. The attackers may attempt to tamper with 𝐴𝑃𝑟 or 𝐴𝑃𝑤 in the metadata to gain more privileges over the victim’s data. To tamper with the metadata, the attacker may choose to modify it by invoking 𝑀𝑑_𝑀𝑜𝑑𝑖𝑓 𝑦, directly tamper with 𝐴𝑃𝑟 and 𝐴𝑃𝑤 stored in the blockchain, or replay the 𝐴𝑃𝑟 and 𝐴𝑃𝑤 . • For 𝑀𝑑_𝑀𝑜𝑑𝑖𝑓 𝑦, DVAC requires the invoker’s identifier to match the stored 𝐼𝐷𝑜 for 𝐼𝐷𝑓 , and the attacker cannot forge a valid signature corresponding to the public key for the stored 𝐼𝐷𝑜 . Consequently, the attacker cannot successfully impersonate the victim to invoke 𝑀𝑑_𝑀𝑜𝑑𝑖𝑓 𝑦.
Page 9 of 14
Enforcing Cryptographic Distributed-VCS Access Control with No Trust on Servers Table 2 Comparison of access control solutions for Git. read permission controla write permission controla key maintenanceb Distributed scenarioc Version control adaptation Data in reposd
git-remote-gcrypt R ✘ 𝑂(𝑁𝑢 ) ✘ P
Git-secret R ✘ 𝑂(𝑁𝑢 ) ✘ P
git-crypt F ✘ 𝑂(𝑁𝑢 ) ✘ P
GitHub Enterprise R B 𝑂(𝑁𝑢 ) ✘ P
Keybase-git R R 𝑂(𝑁𝑢 ) ✘ P
Gringotts F B 𝑂(𝑁𝑢 ) ✘ ✓ C
DVAC in Git F F 2 ✓ ✓ C+S
a
Read/write permission control. " ✘": not supported; "R": repository level; "B": branch level; "F": file level. Key maintenance. " 𝑁𝑢 ": the number of users. c Distributed scenario: no centralized server for file storage or access control implementation. " ✘": not supported or excessive encryption overhead; "✓": support and acceptance of expenses. d Data in repos. "P": plaintext; "C": ciphertext; "C+S": ciphertext+signature. b
• Direct modifications to 𝐴𝑃𝑟 and 𝐴𝑃𝑤 are also infeasible due to the tamper-resistant nature of the blockchain. • Metadata replay attacks cannot succeed either. The attackers cannot perform the read (write) operation once the corresponding permission is revoked, as correct users can obtain a global view of the metadata for 𝐼𝐷𝑓 easily through the query interface of the smart contract, so they are therefore able to obtain the correct metadata for each version of the data. Therefore, DVAC can protect metadata from tampering and resist metadata replay attacks. In addition, the anti-collusion ability of DVAC depends on the anti-collusion ability of ABE and ABS algorithms. The data owner can easily manage the metadata, while the user can obtain any valid metadata through the query interface, without any extra user-side verification.
7. Evaluation In this section, we provide the implementation details and performance evaluation of DVAC.
7.1. Functional Comparison We conducted a functional comparison of DVAC with existing access control solutions for Git, evaluating them based on five aspects: control granularity of read and write permissions, key maintenance overhead, distributed scenario support, and version control adaptation. Our findings indicate that the current Git access control schemes lack the ability to offer fine-grained write access control and struggle to support distributed scenarios, as shown in Table 2. Both git-remote-gcrypt [5] and Git-secret [29] solely offer encryption protection at the repository level and do not support write access control. They utilize GnuPG (GPG) [16] to maintain the public key of all users and provide distribution of symmetric keys. While git-remote-gcrypt uses AES-128 for data encryption, git-crypt [3], similar in nature, employs AES-256 (in CTR mode) for data encryption and can provide file-granular encryption protection. None of these solutions support write access control, and the public key maintained by GPG is either stored on the public key server or maintained X. Xu et al.: Preprint submitted to Elsevier
locally by the user. The 𝑂(𝑁𝑢 ) key maintenance overhead also limits the expansion of distributed scenarios. GitHub Enterprise [11] provides access control services based on the role-based access control (RBAC) model, offering repository-level read access control and branchlevel write access control. However, the implementation of access control requires verification by the GitHub server. Keybase-git [20] is built on the Keybase Encrypted File System (KBFS), and uses the ACL model for access control. Users are also required to maintain 𝑁𝑢 public key information. While these approaches encrypt data during file transfer, the files remain in plaintext in the user’s local repository, thus obviating the need for version control adaptation. Nevertheless, this method cannot guarantee the security of the user’s local data, leaving it vulnerable to potential leakage. Gringotts [41] adopts ABE to encrypt files in the repository, and uses the elliptic curve digital signature algorithm (ECDSA) to provide branch-level write permission control. While ABE allows users whose attributes meet the access policy to decrypt files, the remote server still needs to verify the signature to enforce write access control and maintain 𝑁𝑢 user public keys. In the distributed scenario, there is no central server for access control implementation and file storage, and it is difficult to directly apply to existing DVCS systems (such as Git). In addition, coarse-grained write access control at the branch level requires users to manually generate branches and merge them, which seriously affects user experience in fully distributed scenarios. In fact, Gringotts is a targeted version control system with access control deployed, and its version control function is closely related to the access control function, so the scheme cannot be easily migrated to other DVCS, such as Git. So the above solutions make it difficult to complete the decentralized deployment and application in the DVCS. DVAC, integrated with Git, adopts ABE and ABS algorithms to provide file-granularity read and write access control, enabling fine-grained data protection. Through attributebased cryptographic algorithms, the encryption and signature are calculated according to the attributed access policy. Unlike traditional public key cryptographic algorithms, there is no need to perform encryption for each user and maintain a large number of user public keys. Each user only maintains their own ABE and ABS private keys. Furthermore, DVAC’s Page 10 of 14
Enforcing Cryptographic Distributed-VCS Access Control with No Trust on Servers Total file processing time with 5 attributes
ABE Runtime with 5 attributes
Clean Smudge
22.5
50
40
12.5 10.0
102
File size/KB
Total file processing time with 10 attributes
45
Clean Smudge
40
100 90 80 70 60
102
File size/KB
103
17.5 15.0 12.5
103
102
File size/KB
ABE Runtime with 10 attributes 45
35 30 25 20 15
5
103
ABS Runtime with 10 attributes
Encryption Decryption
Signature Verification
40 35 30 25 20
10
50
20.0
10.0
103
Average Runtime/ms
Average Runtime/ms
15.0
22.5
Average Runtime/ms
File size/KB
110
17.5
7.5 102
Signature Verification
25.0
Average Runtime/ms
60
120
ABS Runtime with 5 attributes 27.5
Encryption Decryption
20.0
70
Average Runtime/ms
Average Runtime/ms
80
102
File size/KB
103
15
102
File size/KB
103
Figure 7: The total file processing time.
read and write access control can be fully implemented on the client side, transparent to users, without the need for a central server. It supports distributed scenarios and is well-suited for distributed version control systems such as Git.
7.2. Performance We have evaluated the performance overhead of enforcing read and write access control introduced by DVAC and compared it to existing schemes. Setting. We have implemented DVAC and integrated it with the Git client. DVAC relies on ABE and ABS to enforce the access control, and integrates with Git through Git filters, i.e., using a clean module for ABE encryption and ABS signing before sharing data, and a smudge module to verify (ABS) signature and (ABE) decrypt the obtained data. The Git client integrated with DVAC was deployed in a MacBook Pro laptop with 4 × 2.3 GHz Intel Core i7-1068NG7 CPUs and 16 GB 3733 MHz LPDDR4X RAM. The metadata were stored in the Ethereum testnet Ropsten [26]. We adopt the ABE algorithm [1] and ABS algorithm [24] in the prototype implementation, and implement them using C language based on the PBC (pairing-based cryptography) library [23]. To evaluate the performance overhead in the practical environment, we measured the introduced latency and storage for different access control policies (one with 5 attributes and the other with 10) and file sizes. The range of file size was set as 0–1 MB, according to our statistics on GitHub dataset with Google BigQuery [7], which is based on the GitHub Archive Project [2]. We analyzed the complete snapshots of the content of more than 2.8 million open-source GitHub repositories until 19 August 2023. As shown in Table 4, 77.44% files are smaller than 10KB, and 99.42% files are smaller than 1MB.
X. Xu et al.: Preprint submitted to Elsevier
7.2.1. Comparison We compared the performance of DVAC with existing Git access control schemes Gringotts [41] and git-crypt [3]. We selected the top 10 repositories with the most stars on GitHub for the experiment. To measure the commit delta time, we replayed 5000 commits in the new repository. DVAC encrypts and signs during git add, so the extra time includes measuring the time to git add all changes in a commit. For Gringotts and git-crypt, this includes the extra time spent encrypting and decrypting files in a commit. Regarding checkout time, we git checkout the first 5000 commits in the clone’s repository and measure the extra time. All repositories were configured with five access policies, each containing 10 attributes in DVAC and Gringotts, and a coarse-grained access policy for 10 users in git-crypt. From Table 3, we can see that the time overhead used by DVAC is close to but slightly lower than git-crypt, and the overhead is higher than Gringotts. This is because Gringotts uses ECDSA for branch-level write access control, while DVAC employs ABS for finer file-level write access control, offering a better user experience for DVCS. Specifically, git add requires ABS signature, and git checkout requires an ABS verification, thus bringing some overhead, which is also explained in detail below. As shown in Section 7.1, unlike Gringotts, DVAC operates without the need for a central server, enabling fully distributed access control. Furthermore, the file-level read and write access control limits permissions to each file version, ensuring that user collaboration, including merge operations, is not disrupted. This also facilitates the implementation of subsequent permission revocations and other policies, allowing DVAC to be used as a plug-in for various DVCS. According to the functional comparison in Table 2, DVAC maintains a time cost within the millisecond range, providing the aforementioned security Page 11 of 14
Enforcing Cryptographic Distributed-VCS Access Control with No Trust on Servers Table 3 Time delta overhead for committing and checking files.
bootstrap d3 electron flutter linux ohmyzsh react tensorflow vscode vue Average
Amortized commit time difference(s) DVAC(git) gringotts git-crypt 0.256 0.16 0.125 0.238 0.168 0.188 0.217 0.167 0.134 0.249 0.161 0.179 0.252 0.17 0.337 0.221 0.167 0.097 0.234 0.184 0.13 0.371 0.243 1.061 0.218 0.14 0.174 0.249 0.159 0.125 0.2505 0.1719 0.255
Table 4 File size statistics on Github (until 2023.8.19). File size 0–10KB 10KB–1MB 1M–10M 10M+
Number
Percentage
205563927 57544225 2097378 236104
77.44% 21.98% 0.79% 0.09%
features without affecting the overall user experience. Overall, DVAC minimizes changes to existing DVCS (such as Git) while implementing distributed mandatory read and write access control independent of a central server, and provides a more adaptable and secure access control scheme for DVCS at an acceptable cost.
7.2.2. Latency We measured the latency for git add passing through the clean module and git checkout passing through the smudge module for different file sizes and access control policies. As shown in Figure 7, for an access control policy with five attributes, the processing time is less than 78 ms and 43 ms for git add and checkout with a 1 MB file, respectively, and the processing time reduced to 67 ms and 33 ms for a 10 KB file. For an access control policy with 10 attributes, the processing time increases slightly, to 94 ms and 46 ms for git add and checkout with a 10 KB file, respectively. In the measurement, the default access policy is not modified. It is assumed that the access policy is cached locally after the metadata is obtained from the blockchain for the first time. The introduced latency consists of three parts: ABE and ABS processing, metadata querying and file transmission between the Git client and the Git filter driver. ABE & ABS processing. ABE and ABS processing requires more than 50% of the whole processing time. As shown in Figure 7, we measure the time overhead of ABE and ABS in DVAC for files with different sizes and access policies with 5 or 10 attributes. The ABE part contains AES-128 symmetric encryption. ABE and ABS processing time increases with file size, and the ABE processing time increases more obviously X. Xu et al.: Preprint submitted to Elsevier
Amortized checkout time difference(s) DVAC(git) gringotts git-crypt 0.128 0.042 0.106 0.155 0.056 0.151 0.143 0.056 0.094 0.152 0.091 0.145 0.198 0.207 0.224 0.113 0.042 0.017 0.125 0.068 0.059 0.271 0.216 0.421 0.184 0.135 0.141 0.112 0.036 0.091 0.1581 0.0949 0.1449
because the file content needs to be encrypted. ABS only hashes the contents of the file and is relatively unaffected. ABE encryption and ABS processing time also increase with the number of attributes of the policy and user, and ABE decryption time is not affected by attributes and policies. For example, for a used 10 KB file, the time for ABE encryption and ABS signature increases from 40 ms to 70 ms when the number of attributes in the policy increases from 5 to 10. The git add operation needs more time than git pull, as ABE encryption and ABS signing require more exponentiations than ABE decryption and ABS verification. Metadata querying. DVAC synchronizes blocks of the Ethereum testnet and queries the metadata locally, which requires about 80 ms when the number of blocks is about 500,000. However, the synchronization of blocks introduces a significant storage overhead; for example, 75 GB is required for 500,000 blocks. To eliminate the storage requirement on the client, DVAC supports to query the metadata through a third-party service (e.g., Infura [19]), which needs 100 ms in our network environment. In addition, the efficiency of metadata querying can also be further improved through methods such as [40]. The transfer latency of metadata creation and modification is similar to the latency of metadata acquisition, both of which are relatively infrequently used and performed by the data owner through web interfaces without integration into the Git client. File transmission between Git client and git filter driver. In DVAC, the transmission of files between the Git client and the Git filter driver occurs using the long-running process protocol. The latency for file transmission is contingent upon the file size, ranging from less than 7 ms for a 1 MB file to 1500 ms for a 10 MB file, and escalating to 98,000 ms for a 100 MB file (the maximum file size in GitHub). Nevertheless, given that sensitive data is typically stored in a separate file and 99.42% of files are less than 1 MB, the latency for file transmission remains within acceptable bounds.
7.2.3. Storage DVAC introduces two extra storage requirements for the Git client. Firstly, each client needs to store the blocks Page 12 of 14
Enforcing Cryptographic Distributed-VCS Access Control with No Trust on Servers
synchronized from the Ethereum testnet, which amounts to 75 GB when the number of blocks reaches approximately 500,000. This storage overhead can be eliminated by using a third-party service (e.g., Infura [19]) for metadata querying. Secondly, each file is stored in the form of ABE ciphertext and ABS signature, rather than the original data. In our setting, this necessitates approximately 5.16 KB of extra storage for each file when a 10-attribute access control policy is employed.
7.2.4. ETH Overhead In the metadata management part, DVAC need to interact with smart contracts, which inevitably involves the overhead of publishing transactions. In the experimental environment, an upload transaction of metadata requires about ETH 0.0005, while a query of metadata does not cost Ether. In addition, if DVCS is built on the basis of multiple alliances or organizations, metadata management can be carried out on the alliance chain, which can greatly reduce the transaction overhead while improving security. Therefore, the overhead of Ether is very small.
8. Discussion DVAC controls read and write permissions using ABE and ABS, respectively, while adapting to DVCS characteristics. It is not tied to any specific DVCS but addresses universal version control and metadata management needs. We developed version control and metadata protocols tailored to Git, enhancing DVAC’s compatibility with it. However, this approach is also applicable to other DVCS systems, which all require version control and distributed security management. Adapting DVAC to different DVCS involves adjusting based on each system’s characteristics, primarily affecting the configuration environment and metadata management deployment, as discussed in Section 5. Regarding attribute-based signcryption algorithms(ABSC), most existing ABSC algorithms support only a single policy mode, such as ciphertext-policy or key-policy.Hybrid schemes [45, 46] combine KP-ABS with CP-ABE but still use a single access policy during the signcryption phase, and generate signature keys based on signature access policies, leading to the need for users to maintain multiple signature keys, especially with varying write permissions across files. In DVAC, we bind signature and decryption keys to attributes separately and bind signatures and ciphertexts to read and write access policies per file. This minimizes user key maintenance overhead and facilitates file permission control. Thus, although ABSC algorithms offer higher computational efficiency and lower communication costs, due to sacrificing some flexibility, existing ABSC algorithms cannot be directly applied to DVAC. Nevertheless, ABSC in principle supports the extension of different access policies, and its integration concept provides us with future optimization directions, so we will consider the possibility of combining ABE with ABS further improve computing efficiency in the future.
X. Xu et al.: Preprint submitted to Elsevier
9. Conclusion In this paper, we propose DVAC, an enforcing cryptographic access control scheme for fully distributed VCS, aimed at preventing unauthorized read or write access to sensitive data in distributed repositories. According to the operation requirements and version control characteristics of DVCS, DVAC sets the enforcing cryptographic access control protocol and version control adaptation protocol. DVAC implements access control on distributed nodes, protecting data access without relying on a central server, and DVAC’s architecture integrates seamlessly with existing DVCS, necessitating only a few straightforward configurations to ensure compatibility. The participation of smart contracts guarantees that only the data owner retains complete control over the shared data and the consistency and security of multi-node access control. We have implemented DVAC, integrated it with Git, and the performance evaluation demonstrates that the introduced overhead is acceptable in practical environment. Our current scheme also has some limitations, such as the high computational cost of attribute-based cryptography and the undiscussed fine-grained permission dynamic management. Future research will focus on optimizing distributed system access control, such as multi-authority fine-grained retractions, and developing smart contract-assisted computing schemes for resource-limited devices, in order to improve system efficiency and the scope of application.
Acknowledgements This work was supported by National Natural Science Foundation of China (No.82090053). The authors wish to thank anonymous reviewers for their valuable comments and suggestions that improved this paper.
References [1] Agrawal, S., Chase, M., 2017. FAME: fast attribute-based message encryption, in: Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security, CCS 2017, Dallas, TX, USA, October 30 - November 03, 2017, ACM. pp. 665–682. [2] archive, G., 2023. Github Archive. Retrieved from https://www. gharchive.org/. Accessed February 29, 2024. [3] Ayer, A., 2012. Git-crypt. Retrieved from https://www.agwa.name/ projects/git-crypt/. Accessed February 29, 2024. [4] Bethencourt, J., Sahai, A., Waters, B., 2007. Ciphertext-policy attribute-based encryption, in: IEEE Symposium on Security and Privacy, IEEE. pp. 321–334. [5] Bluss, 2021. Git-remote-gcrypt. https://spwhitton.name/tech/code/ git-remote-gcrypt/. Accessed February 29, 2024. [6] Christidis, K., Devetsikiotis, M., 2016. Blockchains and smart contracts for the internet of things. IEEE Access 4, 2292–2303. [7] Cloud, G., 2023. GitHub Activity Data. Retrieved from https:// console.cloud.google.com/marketplace/product/github/github-repos. Accessed February 29, 2024. [8] Contracts, S., 2022. Smart contracts. Retrieved from http://szabo. best.vwh.net/smart.contracts.html. Accessed February 29, 2024. [9] CVS, 2019. Concurrent versions system. Retrieved from https: //www.nongnu.org/cvs/. Accessed February 29, 2024. [10] Di Vimercati, S.D.C., Foresti, S., Jajodia, S., Livraga, G., Paraboschi, S., Samarati, P., 2013. Enforcing dynamic write privileges in data outsourcing. Computers & Security 39, 47–63.
Page 13 of 14
Enforcing Cryptographic Distributed-VCS Access Control with No Trust on Servers [11] Enterprise, G., 2022. A smarter way to work together. Retrieved from https://github.com/enterprise. Accessed February 29, 2024. [12] Exceline, C.E., Nagarajan, S., 2024. Flexible access control mechanism for cloud stored ehr using consortium blockchain. International Journal of System Assurance Engineering and Management 15, 503–518. [13] hyperledger fabric, 2023. A blockchain platform for the enterprise. Retrieved from https://hyperledger-fabric.readthedocs.io/. Accessed February 29, 2024. [14] Git, 2024a. distributed-even-if-your-workflow-isnt. Retrieved from https://git-scm.com. Accessed February 29, 2024. [15] Git, 2024b. Git attributes: long-running-filter. Retrieved from https: //git-scm.com/docs/gitattributes. Accessed February 29, 2024. [16] GnuPG(GPG), 2024. The gnu privacy guard. Retrieved from https://www.gnupg.org/. Accessed February 29, 2024. [17] Goyal, V., Pandey, O., Sahai, A., Waters, B., 2006. Attribute-based encryption for fine-grained access control of encrypted data, in: ACM Conference on Computer and Communications Security, pp. 89–98. [18] Huang, M., Liu, Y., Yang, B., Zhao, Y., Zhang, M., 2024. Efficient revocable attribute-based encryption with data integrity and key escrow-free. Information 15, 32. [19] Infura, 2024. Unleash the full potential of web3. Retrieved from https://infura.io/. Accessed February 29, 2024. [20] Keybase, 2017. Keybase launches encrypted git. Retrieved from https: //keybase.io/blog/encrypted-git-for-everyone. Accessed February 29, 2024. [21] Li, X., Wang, H., Ma, S., 2025. An efficient ciphertext-policy weighted attribute-based encryption with collaborative access for cloud storage. Computer Standards & Interfaces 91, 103872. [22] Li, X., Wang, H., Ma, S., Xiao, M., Huang, Q., 2024. Revocable and verifiable weighted attribute-based encryption with collaborative access for electronic health record in cloud. Cybersecurity 7, 1–19. [23] Lynn, B., 2006. The PBC(Pairing-Based Cryptography) Library. Retrieved from http://crypto.stanford.edu/pbc/. Accessed February 29, 2024. [24] Maji, H.K., Prabhakaran, M., Rosulek, M., 2011. Attribute-based signatures, in: International Conference on Topics in Cryptology: CTRSA. [25] Patil, R.Y., 2024. A secure privacy preserving and access control scheme for medical internet of things (miot) using attribute-based signcryption. International Journal of Information Technology 16, 181–191. [26] Ropsten, 2023. TESTNET Ropsten (ETH) Blockchain Explorer. Retrieved from https://ropsten.etherscan.io/. Accessed February 29, 2024. [27] Ruj, S., Stojmenovic, M., Nayak, A., 2012. Privacy preserving access control with authentication for securing data in clouds, in: International Symposium on Cluster, Cloud and Grid Computing, pp. 556–563. [28] Sahai, A., Waters, B., 2005. Fuzzy identity-based encryption, in: Annual International Conference on the Theory and Applications of Cryptographic Techniques, Springer. pp. 457–473. [29] git secret, 2022. Bash-tool to store your private data inside a git repository. Retrieved from https://sobolevn.me/git-secret/. Accessed February 29, 2024. [30] Shafagh, H., Burkhalter, L., Ratnasamy, S., Hithnawi, A., 2020. Droplet: Decentralized authorization and access control for encrypted data streams, in: 29th {USENIX} Security Symposium ({USENIX} Security 20), pp. 2469–2486. [31] sitaramc, 2014. Gitolite. Retrieved from http://gitolite.com/. Accessed February 29, 2024. [32] slobobaby, 2014. Git filter. Retrieved from https://github.com/ slobobaby/git_filter. Accessed February 29, 2024. [33] SVN, 2023. Apache subversion. Retrieved from https://subversion. apache.org/. Accessed February 29, 2024. [34] Systems, C., 2024. Web3.js. Retrieved from https://github.com/ ethereum/web3.js/. Accessed February 29, 2024. [35] Thwin, T.T., Vasupongayya, S., et al., 2019. Blockchain-based access control model to preserve privacy for personal health record systems. Security and Communication Networks 2019.
X. Xu et al.: Preprint submitted to Elsevier
[36] Veracity, 2014. An open source, distributed version control and bug tracking system for windows, mac os x, and linux. Retrieved from http://veracity-scm.com/. Accessed February 29, 2024. [37] Vimercati, S.D.C.D., Foresti, S., Jajodia, S., Paraboschi, S., Samarati, P., 2007. Over-encryption: Management of access control evolution on outsourced data, in: International Conference on Very Large Data Bases, pp. 123–134. [38] Wang, S., Wang, X., Zhang, Y., 2019. A secure cloud storage framework with access control based on blockchain. IEEE access 7, 112713–112725. [39] Wood, G., et al., 2014. Ethereum: A secure decentralised generalised transaction ledger. Ethereum project yellow paper 151, 1–32. [40] Wu, H., Peng, Z., Guo, S., Yang, Y., Xiao, B., 2022. VQL: efficient and verifiable cloud query services for blockchain systems. IEEE Trans. Parallel Distributed Syst. 33, 1393–1406. [41] Xu, W., Ma, H., Song, Z., Li, J., Zhang, R., 2023. Gringotts: An encrypted version control system with less trust on servers. IEEE Transactions on Dependable and Secure Computing . [42] Xu, X., Cai, Q., Lin, J., Pan, S., Ren, L., 2019. Enforcing access control in distributed version control systems, in: 2019 IEEE International Conference on Multimedia and Expo (ICME), IEEE. pp. 772–777. [43] Yang, Z., Chen, X., He, Y., Liu, L., Che, Y., Wang, X., Xiao, K., Xu, G., 2024. An attribute-based access control scheme using blockchain technology for iot data protection. High-Confidence Computing 4, 100199. [44] Yin, S., Li, H., Teng, L., Laghari, A.A., Estrela, V.V., 2024. Attributebased multiparty searchable encryption model for privacy protection of text data. Multimedia Tools and Applications 83, 45881–45902. [45] Yu, G., Cao, Z., 2017. Attribute-based signcryption with hybrid access policy. Peer-to-Peer Networking and Applications 10, 253–261. [46] Yu, J., Liu, S., Wang, S., Xiao, Y., Yan, B., 2020. Lh-absc: A lightweight hybrid attribute-based signcryption scheme for cloud-fogassisted iot. IEEE Internet of Things Journal 7, 7949–7966. [47] Zhang, Y., He, D., Choo, K.K.R., 2018. Bads: Blockchain-based architecture for data sharing with abs and cp-abe in iot. Wireless Communications and Mobile Computing 2018. [48] Zhao, F., Nishide, T., Sakurai, K., 2011. Realizing fine-grained and flexible access control to outsourced data with attribute-based cryptosystems, in: International Conference on Information Security Practice and Experience, pp. 83–97.
Page 14 of 14