[论文分享]基于区块链技术的服务端资源权限控制系统设计与实现

前情

这几年对区块链进行了学习也算是有些感悟想以类似论文的形式将一些想法表现出来这也能严谨一些文章组织也更有条理分享给大家希望能与大家多交流。在我来看区块链是一项技术在某一点上往往难以量化其优点和贡献的这就更需要去深入详细的思考了解其特性可以带来的变革。

0.引言

随着区块链技术的兴起互联网浪潮逐渐从web1.0、web2.0向web3.0转变。去中心化浪潮使得用户由信息的接收者、沟通者转为信息的提供者及制造者。数据逐渐由传统的寡头公司转移到用户手中随之而来的则是用户对身份主权、数据主权的回收与支配最终实现价值的普惠流动。这个去中心化既是计算上的去中心也是存储上的去中心化。然而就当前而言web3.0也不可避免地过于理想化治理挑战、技术挑战、监管挑战都对其大规模落地带来影响。在很长一段时间内网络上都将会出现中心化与去中心化并存的情形中心化服务提供商基于基于去中心化技术支撑对网络上的用户提供服务。在此背景下原本中心化的服务端应当处理好中心化与去中心化的权衡在其中更要做好权限管理工作。

用户的权限控制是个敏感的话题涉及到用户与服务提供商之间的信任问题。传统的权限控制系统由用户发出操作申请由服务器程序在后端完成并存储整个过程存在权限、数据的中心化问题无法保证用户权限分发控制的不可篡改性及公开可追溯性且用户并未全程参与信任问题尚未解决。此外用户的权限分发也对权限控制提出了更高的要求基于信息管理的传统权限控制方法往往难以满足。因此实现可信、可追溯的权限管理控制具有重要的工程意义和应用价值。本文基于区块链技术设计了一种服务端资源权限控制系统包括资源权限分发转移机制及基于权限的资源控制方法有效地解决了Web3.0趋势下权限控制难、中心化的问题具有一定的工程价值及研究意义。

1. 背景介绍

近年来随着互联网技术的不断进步互联网用户与服务提供商的角色也发生悄然转变。Web1.0时代网站是信息及数据的提供者用户参与信息的浏览和使用。Web2.0时代用户逐渐参与到资源、数据的创建中来基于中心化服务进行交换、沟通但数据、权限控制等仍为网站所持有。2020年来Web3.0概念逐渐兴起在去中心化浪潮下用户逐渐走向舞台的中心对资源、数据、权限的控制权逐渐回到用户手中凭借身份凭证用户逐步可以实现对数据、权限的自主控制。因此在此转变趋势下服务端的权限控制方法也应随之发生改变。

传统RBACRole-Based Access Control

传统的权限控制方法是基于资源数据作为资源存储在社区的服务端而权限则通过数据库中用户-角色-权限的数据表标识用户如要访问资源服务端则会首先对用户在受访问资源上的权限进行校验最终给出授权与否的判断。 国内外对此进行过一些研究早在1995年D Ferraiolo及 J Cugini等人就对基于角色的准入控制进行了研究从此RBACRole-Based Access Control逐渐进入国内外学者的视野。2002年清华大学的林磊等人对授权的行为模型展开了研究并在RBAC的基础上提出了一套使用于MIS系统的权限控制应用模型。2012年北京工商大学的李双提出了一种扩展的RBAC模型ERBAC不仅继承了传统RBAC的所有优势同时可以不做修改的嵌入到工作流系统中并实现动态访问控制。武汉理工大学的向奎在2013年设计了一个可接口集成数据集成流程集成的基于角色访问控制的通用用户权限管理系统实现了用户和权限的逻辑分离能够动态的为用户分配权权限。2016年及2020年同济大学的邵剑雨等人及河南师范大学的张荣荣分别实现了基于动态信任值的访问控制方法及具有可维性的三位权限控制模块前者通过动态调整用户信任值克服了当前访问控制在移动互联网环境下安全性不足的缺点并有效控制用户在不同状态下对不同资源的访问权限后者在RBAC的基础上加入组织和角色组以实现权限体系的可复用及可扩展。尽管研究卓有成效但传统的权限控制方法原生地存在局限性权限本身也作为数据字段存储在服务端而用户对权限的控制本质上是请求对服务端数据的更改这将不可避免地带来中心化问题用户难以确保自己对权限的排它性、准入性同时也难以保证用户权限分发控制的不可篡改性及公开可追溯性导致用户与服务端间的信任问题。

区块链与权限的结合

意识到传统权限控制方法的局限性国内外学者结合了新兴的区块链技术对此做出了一些改进具体包括以下2017 年卡迪阿雅德大学的Aafaf等人基于区块链技术为物联网环境设计了名为FairAccess的权限控制框架并通过进行了试验。一年后奈良科技大学的Yuanyu Zhang等人同样为物联网环境设计了基于智能合约的权限控制框架利用智能合约实现权限的动态控制。2020年汪利鹏等人提出了区块链协同权限控制方法及装置通过公私钥实现用户对于共享资源的鉴权请求及浏览实现业务关联方数据共享。2021年苏州科学技术大学的的石鹏展提出一种对称加密的数据权限管理方案,实现对存储在区块链中的隐私数据的访问控制。同年国防科技大学的舒展鹏等人对指挥信息系统用户权限管理问题展开研究利用区块链的多链架构划分指挥信息系统的业务席位实现操作行为的统一规范管理。但整体看来目前并未对技术进行整合并建立统一、有效的权限管理机制。

技术背景

在区块连浪潮下用户的个人信息将已不再以用户名-密码的形式储存在服务端而是以私钥-公钥及地址的身份存在于分布式网络中其示意图如图1所示。用户在首次进入网络后通过加密算法如椭圆加密等生成私钥-公钥对私钥由用户个人持有对应用户密码公钥及地址则对外可见作为用户对外身份所展示。用户使用私钥签名在服务端端使用公钥进行验证验证用户身份并以此为用户的操作进行授权。而区块链本质上是链接在一起的区块数据Merkle哈希树使得其难以篡改极其微小的修改也会带来区块哈希值的巨大变化。数据的更改和转移以交易的形式存入区块并记录在链上任何人都无法篡改这也保证了权限管理的透明性、不可否认性。

本文基于区块链技术针对中心化、去中心化并存的网络环境中设计了一种服务端资源权限控制系统该系统以用户为核心面向资源设计有效地解决了资源权限控制难、权力中心化的问题。本文对该系统的核心组件进行了实现并与传统资源权限控制系统展开了对比。同时本文也对未来Web3.0社区数据、存储、权限去中心化的趋势进行了探讨具有一定的工程价值及研究意义。

2. 基于智能合约的资源权限分发转移机制设计

用户的活动与交互会产生、创建资源资源可以是文本、语音、数据接口等等而用户则拥有该数据的所有权限不被其他用户随意访问、占用。这就要求资源尤其是敏感资源的所有权、使用权应在网络中是透明的、不可篡改的。基于区块链技术建立智能合约将权限通过Token凭证/代币进行实体化即可保证用户权限的不可篡改。具体示意图如下图所示

用户与服务端链上部分均可接入区块链网络作为节点而存在。链上有多个全节点或轻节点全节点可验证、提交交易并对外广播。而轻节点可通过与全节点的通信查询交易信息。用户与服务提供商之间通过HTTP服务进行正常通信用户通过数字签名向服务端进行身份证明随后进行活动并进行资源的创建。在此过程中如产生部分敏感资源资源将加密存储至中心化服务器且服务端链上部分应实现权限上链保证资源访问及权限转移的透明性。

在资源创建完成后服务端将为该资源创建智能合约合约的Token代币则标识对资源的所有权。在该合约的创世区块中该合约将权限代币分配给资源的创建用户。如果有多个用户同时参与了资源的创建过程则权限代币将被按比例发送到各个用户的地址中去。生成Token的量取决于资源被访问的手段及Token是否会被销毁。正如商品在市场上自由流通资源也可以在用户之间共享、转移这就体现在代币的转移。当两个用户之间需要转移资源的权限时资源所有者可以从身份地址将代币部分或所有转移至新用户的地址代币的转移过程只在链上进行服务端仅能对交易进行观察而无法对交易进行干涉。权限代币的转移示意图如下图所示

如果用户想放弃对资源的权限可以直接将所有权限代币打入黑洞0x00000…dead即将权限代币转移至黑洞地址此时用户不再拥有权限代币已失去对于该资源的控制权完成了权限的销毁。

3.基于上链权限的资源控制方法设计

基于权限的资源控制不仅包括对于权限的认证同时也包括基于权限对资源的加密控制。尽管权限已经上链解决了用户的权限生成、转移、销毁的中心化问题但系统仍需要对于资源进行妥善处理如加密存储等否则用户-服务端间的信任问题仍然难以解决。本节将介绍基于权限凭证的认证与授权、权限代币的重新分发及资源的加密访问。

基于权限代币的认证与授权

用户所创建的资源存储在中心服务器中并为验证器所保护。当资源受到访问时验证器向链上的节点发出请求请求中附带用户的身份即地址及该资源所对应的合约以验证链上用户的地址是否包含对应资源的权限代币。如果不满足则用户的请求将被驳回如果用户的链上地址存在权限代币且其数量满足特定要求如代币的数量等则用户将被认证为资源的所有者并被授权用户即可实现对于资源的访问。基于权限代币的认证与授权过程如下图所示

权限代币的回收与重新分发

权限代币代表着用户对于资源的所有权但其所有权不是一成不变的。正如代币具有支付属性用户在访问资源时也可以扣除一定的权限代币。此时资源的访问就具有了计量属性用户对资源的访问也要付出相应的代价当用户的代币不足以支付资源访问所需的花费时该操作将被中心化服务器的验证器所拒绝。当用户选择消耗权限代币进行访问时用户所支付的代币则会被转移到验证器的链上地址中并通过重新分发或销毁机制进行流转。

资源的加密存储及控制

当资源存储在服务器端这不可避免地对数据、资源的安全性带来了挑战。当用户进行登陆操作并进行内容创作时资源文件在离开用户端前就会被切分成多块在用户端使用公钥进行加密并发送至服务器。此时其余用户由于不知道私钥所以资源难以被访问。当资源的权限需要转移时在用户转让端由用户使用私钥对数据解密还原明文资源、数据再使用受让端公钥对数据加密最后并传回服务端。服务端在资源的产生及权限转移过程中均不接触原始数据从而保证了数据的隐秘性和安全性。

4. 服务端资源权限控制系统核心组件实现

本文基于以上设计实现了服务端资源权限控制系统核心组件组件包括私有链的搭建、权限智能合约编写及验证器系统组成如下图所示。

本文基于Geth工具搭建了私有链对外开放rpc端口实现底层支撑保障智能合约的运行。同时本文结合ERC20及ERC721智能合约接口框架实现了资源权限控制智能合约合约代码段具体组成如下所示。其中server变量代表服务器名称tokenOwners变量是tokenId即资源编号到资源所有者地址的映射tokenBalance则是用来寻找给定资源下给定用户的资源凭证代币数量。_mint方法则由服务端发起生成资源代币并指定所有人。transfer方法和destroy方法则是对资源代币的转移和销毁。checkBalance方法则允许服务器调用以查看指定用户所拥有的指定资源凭证的数量。

本文基于Golang的Echo框架搭建了服务端验证器。验证器由eths模块、routes模块、config模块及utils模块组成。eths模块储存Solidity智能合约的abi及编译后的go文件并基于go-ethereum编写账户管理及合约交互代码。routes模块基于Echo框架对外提供http服务函数可供服务端调用对内则调用eths模块。config模块支持对keystore文件存储位置、智能合约地址及私有链接入点rpc地址进行配置。utils则支持对网络请求处理及相关的文本处理。

本文对系统的功能展开了测试测试结果表明合约的创建、权限代币的生成、转移均在链上可查同时非授权对象对权限代币的更改也将被拒绝。合约链上交互截图如下图所示。



测试结果表明设计的基于区块链技术的服务端资源权限控制系统能够达到权限上链、透明控制的目标本文将其与传统基于角色的权限控制方法进行了对比对比情况如下表所示。由表可知基于区块链技术的服务端资源权限控制将权限上链权限所有对象从服务端改为权限所有用户整个管理过程透明、去中心话很好地解决了用户与服务端之间的信任问题。

	存储形式	存储位置	所有对象	是否透明	是否中心化
RBAC	数据库字段	服务端	服务端	否	是
基于区块链的权限控制	智能合约代币Token	链上	权限所有用户	是	否

5. 思考不足与展望

本文基于区块链技术设计了一种服务端资源权限控制系统有效地解决了权限控制难、中心化的问题然而当前的设计依然存在一定的问题具有一定的局限性。本文将对此做出探讨并提出可能的改进措施。

1. 每当用户进行资源的创建就会为该资源数据生成相关的权限代币。尽管这可以批量化、自动化进行但有可能会出现粒度过细的问题往往会造成算力、存储空间的浪费。实际上用户仅需要保证隐私、重要数据的安全对于隐私性、重要性要求不高的资源或数据可以明文在服务器中存储这样资源的浪费问题能达到很大程度的缓解。又或者用户可以通过同一份智能合约基于映射数据结构实现对于多份资源的权限控制。
2. 数据存储时为了数据的隐秘性服务器端对数据的实际内容应是不可知的这使得明文的加密及密文的解密都应当在用户端进行。以上对用户端的性能提出了一定要求。实际上服务端应对数据、资源的规模做出了限制不满足的将被驳回否则非对称加密会使得数据加密、传输的时延难以令人接受。
3. 数据经加密后仍然存储在服务端但却无法被社区服务所直接访问需通过验证器进行中继而权限的上链查询会降低用户访问资源的流畅性服务端故障也会导致数据的丢失与不可恢复。实际上这可以通过优化区块链性能进行改善。同时为了彻底实现数据的去中心化存储也可采用诸如IPFS星际文件系统等分布式文件存储技术此时数据完全不依赖于中心化服务器的位置但相应服务的实时性、易用性也会受到相当程度的影响。服务提供商在架构设计选择时应当做好权衡以达成平衡。

6. 结束语

在去中心化浪潮下中心化服务端应当处理好中心化与去中心化的权衡实现数据、资源的权限控制。本文基于区块链技术提出了一种服务端资源权限控制系统包括资源权限分发转移机制及基于权限的资源加密存储、控制方法。尽管该系统仍存在算力浪费、性能要求较高的趋势仍未彻底实现数据的去社区化及去中心化但仍在中心化与分布式决策权衡提供了思路。希望随着科技的发展更多分布式技术能够涌现为人们提供便利。

7 附录

智能合约代码

以下是权限管理的智能合约代码欢迎交流。

pragma solidity ^0.6.0;
pragma experimental ABIEncoderV2;

import "./openzepplin/Ownable.sol";

contract ResourceAuthorizationManagement is Ownable{

    event Transfer(address indexed from, address indexed to, uint256 tokenId, uint256 tokenAmounts);

    // ---------------------------------------------------------------------------
    string public server;
    mapping(uint256 => address) public tokenOwners;
    mapping (uint256 => mapping(address => uint256)) tokenBalances; 
    mapping (uint256 => string) public tokenDescriptions;

    // ---------------------------------------------------------------------------
    constructor(string memory servername) public {
        server = servername;
    }

    // ---------------------------------------------------------------------------
    modifier _ifTokenExist(uint256 tokenId){
        require(tokenOwners[tokenId]!=address(0x0),"TokenId non-exist");
        _;
    }

    modifier _isOwnableOfToken(uint256 tokenId, address add){
        require(tokenOwners[tokenId]==add,"Not valid user of the token");
        _;
    }

    modifier _hasSufficientAmount(uint256 tokenId, uint256 amounts){
        require(tokenBalances[tokenId][msg.sender] >= amounts,"No sufficient token");
        _;
    }
    // ---------------------------------------------------------------------------

    function _mint(uint256 tokenId, address tokenOwner, uint256 tokenAmount, string memory tokenDescription) public onlyOwner(){
        tokenOwners[tokenId] = tokenOwner;
        tokenBalances[tokenId][tokenOwner] = tokenAmount;
        tokenDescriptions[tokenId] = tokenDescription;
    }

    function transfer(address to, uint256 tokenId, uint256 amounts ) public _hasSufficientAmount(tokenId,amounts) {
        tokenBalances[tokenId][msg.sender] -= amounts;
        tokenBalances[tokenId][to] += amounts;
        emit Transfer(msg.sender,to,tokenId,amounts);
    }

    function destroy(uint256 tokenId) public _isOwnableOfToken(tokenId,msg.sender){
        transfer(address(0x0),tokenId,tokenBalances[tokenId][msg.sender]);
    }

    function checkBalance(address addr, uint256 tokenId) public view _ifTokenExist(tokenId) returns (uint256){
        return tokenBalances[tokenId][addr];
    }
   
}