基于区块链的多部门数据共享访问控制流程建模

蒋家昊，张 璇,2,3+，邓宏镜，王 杰，黄河祥

(1.云南大学 软件学院，云南 昆明 650000；2.云南大学 云南省软件工程重点实验室，云南 昆明 650000；3.云南大学 教育部跨境网络空间安全工程研究中心，云南 昆明 650000)

0 引言

目前，由于互联网通信技术和物联网技术的快速发展，大数据已经渗透到生活中，良好的数据交互方式为各部门、各企业提供了便捷的数据共享，企业或政府部门可以利用大数据技术挖掘海量数据中的潜在价值，以帮助自身提高服务质量、了解用户意愿、推动产业升级[1]。在实际应用中，部门之间往往通过云服务器、物联网等方法进行数据交互，从而使存储和计算资源得到充分利用。然而，这些访问方式仍然存在安全隐患，集中式管理方法可能导致数据泄露，无法保障数据访问的安全性。例如，在边境口岸出入境业务流程中，面向国际贸易的出入境人员首先需要申请各种许可证书，其需要在公安局、海关部门、工商局、交管等多个不同部门之间往返，这些部门间需要经常共享和访问数据，如何确保数据的一致性、真实性、完整性和合法性显得尤为重要。

目前，面向多部门间的访问控制模型均基于单一的访问控制技术，如基于角色的访问控制(Role-Based Access Control, RBAC)、基于属性的访问控制(Attribute-Based Access Control, ABAC)等，然而这些技术各有弊端。例如，RBAC缺乏对管理员授权操作的限制，容易滥用角色权限，ABAC容易暴露敏感属性。为了提高多部门多企业间数据共享的安全性，改善现有访问控制模型的不足，本文面向边境口岸的出入境信息共享业务，基于HyperledgerFabric联盟链，混合基于属性、能力的访问控制技术，提出一种基于区块链的多部门数据共享访问控制方法CABAC(capability-attribute based access control)。CABAC模型在继承ABAC模型灵活性的基础上引入能力令牌，通过不同角色各自具有的属性分配相应的访问权限，并生成相应的能力令牌，用户可以根据访问策略将自身拥有的能力令牌委派给其他用户，获得能力令牌的用户便能对访问对象执行相应的操作。相比现有的访问控制模型，该模型优化了繁琐重复的身份验证过程，允许具有相同属性的用户之间进行能力委派，具有更好的灵活性。同时，与其他基于能力的访问控制(Capability-Based Access Control, CBAC)模型不同，本文的能力令牌用单个能力划分，一个用户可以同时拥有多个能力令牌，因此在权限委派上具有更细的粒度。

本文的主要贡献如下：

(1)首次提出混合基于属性和能力访问控制模型的数据共享访问控制方案，通过开发链码在实施访问控制的前提下引入CBAC，以更细的粒度进行访问能力的生成与委派，目前尚未有类似的方案。

(2)针对面向多部门的出入境场景提出基于HyperledgerFabric联盟链和星际文件系统(InterPlanetary File System, IPFS)的无中心安全信息存储管理框架，对信息业务管理流程进行建模、阐述和分析，同时提供了标准可信的业务操作流程，能够保证多部门协同过程中的数据不可篡改，而且业务流程按照约定的顺序执行，更符合多部门间数据共享的要求。

1 相关工作

1.1 中心化的访问控制

访问控制技术最早可以追溯到1960年代提出的多级安全概念，由许多规则和法规组成，旨在对访问计算、存储、服务等资源设置条件，以确保安全访问信息。随着技术的发展，出现了自主访问控制(Discretionary Access Control, DAC)和强制访问控制(Mandatory Access Control, MAC)，然后产生RBAC[2-3]和ABAC[4]。RBAC将用户映射到角色，通过角色享有许可，通过定义不同角色与其之间的关系来规范用户的行为，然而在开放的网络环境中，RBAC无法适应复杂的环境，且存在角色爆炸问题；ABAC针对复杂信息系统中的细粒度访问控制和大规模用户动态扩展问题，将实体属性的概念联系在一起，通过对主体、客体、权限和环境统一建模进行访问控制。GUSMEROLI等[5]提出CBAC模型，访问权限以令牌(token)的形式存在，通过为实体赋予权限实施访问控制，同时支持权限的委派和撤销。然而，以上模型均基于中心化的架构，用户无法得知自己数据被使用的情况。随着云端技术与区块链技术的成熟，传统访问控制模型的弊端逐渐显露出来。

1.2 基于区块链的访问控制

自从NAKAMOTO等[6]首次提出比特币区块链后，区块链技术即被广泛应用于金融、医疗、交通等领域。访问控制技术可以很好地与区块链技术结合，达到对共享数据、物联网设备和公共服务的访问控制。CRUZ等[7]将RBAC与以太坊智能合约结合，提出使用智能合约的基于角色的访问控制(Role Based Access Control using Smart Contract, RBAC-SC)框架，采用智能合约创建和分配用户角色，同时提出质询—响应协议对角色的所有权、分配权进行验证；ZHU等[8]通过集成ABAC和区块链技术，将基于事务的访问控制(Transaction-Based Access Control, TBAC)运用于数字资产管理服务，开发了DAM-Chain数字资产管理平台，能够保存和发布主体与对象，发起访问请求并授权。为了解决物联网(Internet of Things, IoT)设备分布广泛但资源有限，难以采用传统方法抵御恶意攻击的问题，ZHANG等[9]同样提出一种RABAC方案，其在区块链网络中将节点分为授权节点和公共节点，将IoT设备与区块链分开，引入授权节点充当区块链客户端，授权节点可以通过查询部署过的链码，检索已经注册的访问凭证，来验证请求者的身份及访问策略的有效性；NAKAMURA等[10]以CBAC为基础，通过以单独的能力作为基本单位来定义能力令牌，将传统的能力令牌划分为多个单独的能力令牌，实现了更细粒度的访问控制和更灵活的令牌管理；QI等[11]考虑区块链分布式的基础架构将物联网中的产品信息直接存储在链上会导致数据管理的效率和隐私问题，开发了Cpds压缩数据共享框架，通过链下的方式在参与者将数据提交到区块链上之前对数据进行压缩和加密，用户使用时再根据策略解密，使大型工业系统通过安全有效的方式存储和访问大量产品数据；ZHANG等[12]为解决智能电网数据共享中的隐私保护和数据安全问题，提出一种具有隐私保护的多权限属性加密方案；LYU等[13]提出一个基于区块链的安全访问控制框架，引入基于区块链的访问令牌机制实现对内容的共享、审核和撤销，同时引入布谷鸟过滤器提高验证中令牌访问查询的效率；YANG等[14]提出一种基于属性加密和区块链技术的医疗数据共享方案，该方案结合基于属性的加密和基于属性的签名，实现了数据隐私和细粒度的访问控制机制；ULLAH等[15]提出一种基于区块链的数据共享和访问控制系统用于物联网设备之间的通信，该系统通过访问控制智能合约实现了物联网中数据共享的信任、授权和认证；XU等[16]提出一种具有鲁棒性的、基于身份的能力令牌管理策略，利用智能合约对访问控制进行注册、委派和撤销；BANERJEE等[17]为了使用物联网环境中的数据，提出具有恒定大小密钥和密文的多权限属性加密方案；LIANG等[18]为了解决集中式医疗服务系统中的信息孤岛问题，提出一个基于轻量级信息共享的医疗区块链系统，使用交织编码器对原始电子病历进行加密。不同于已有工作，本文提出一种混合访问控制框架，在ABAC的基础上结合CBAC，能够以更细粒度的模式实现访问能力的生成和委托，同时在数据存储上引入IPFS来减轻区块链的数据存储压力。

2 总体框架设计

本章介绍了CABAC框架，模拟了不同部门对边境口岸出入境信息的访问控制流程，通过制定适当的访问策略和属性也可将本框架拓展到其他领域。与现有工作不同的是，本文首次提出一种混合访问控制框架，该框架在RABAC中引入CBAC，可在实施访问控制的前提下以更细的粒度进行访问能力的委派。

任何访问控制系统的目的都是谁(主体)可以对什么资源(对象)进行什么操作(或设置权限)[5]，本文设计的访问控制框架涉及如下元素：

S={si}，为系统中所有主体的集合；

O={oj}，为系统中所有对象的集合；

OP={opk}，为系统中声明的操作的集合(如读、写、执行)；

C={cl}，为系统中所有环境上下文的集合(如时间)；

CAP={capm}，为系统中所有能力令牌的集合。

访问控制系统可以定义为

opk∈OP,cl∈C,capm∈CAP

for somei,j,k,l,m。

该规则表示任意一个访问控制系统都能由连接了主体S、对象O、操作OP、环境上下文C和能力令牌CAP的规则集∑n定义。

出入境人员和各部门人员可以通过智能手机或个人电脑访问区块链网络，从而执行访问控制，如图1所示。图中，本文所提框架由联盟区块链和IPFS组成，主要参与者有检疫部门、交管部门、海关部门和公安部门。由于在边境口岸出入境信息共享业务流程中涉及海量数据，包括图片类型的数据(如许可证、车辆的照片等)，区块链技术可以提供数据共享查询通道，但是存在缺陷。例如区块的大小限制了存储在区块链上的文件数量和类型，在比特币区块链中，每个区块的大小仅为1 M，能够存储的信息十分有限，因此本文用IPFS以链下存储的方式对区块链的可存储行进行拓展，将图片文件存储在IPFS中，同时将其返回的Hash值存储到区块链上，检索时只需要对应文件的Hash值即可在IPFS中查询到相应的文件。访问控制部分主要涉及属性管理合约(Attribute Management Contract, AMC)、策略管理合约(Policy Management Contract, PMC)、令牌生成合约(Token Generation Contract, TGC)、令牌管理合约(Token Management Contract, TMC)和访问控制合约(Access Control Contract, ACC)5个智能合约。在访问控制过程中，AMC负责存储和管理主体和对象的属性，PMC负责存储和管理访问控制策略，TGC负责根据策略生成相应的能力令牌，TMC负责存储和管理已有的能力令牌，ACC负责基于以上信息响应访问请求，智能合约的详细设计见3.1节。

2.1 实现访问控制的智能合约设计

在图1所示的CABAC框架中涉及AMC，PMC，ACC，TGC，TDC 5个智能合约，其中AMC，PMC，ACC与RABAC有关，负责存储和管理主体、对象属性与访问策略；TGC和TDC与CBAC有关，负责生成和委派相应的能力令牌。

(1)AMC负责对主体和对象的属性进行存储和管理。AMC由管理员部署，而且只有管理员有权限执行它。在本文模拟的多部门系统中，主体可以为各个部门中的职员，管理员可以为各部门中的行政主管，如果主体为物联网中的设备，则管理员可以为其拥有者。为了区分不同的主体，每个主体都有唯一的标识符指定其身份，对象同理。在本系统中，用HyperledgerFabric中证书颁发机构CA颁发的证书作为身份标识信息，如表1中的“MI9ZT…”。表1所示为主体属性和对象属性的举例展示，例如主体[MI9ZT…]的姓名为Alice，所属部门为海关，所属科室为税务室，职位为主管等；对象[FU1B3]是姓名为“Bob”的物联网设备，所属部门为检疫部门，所属科室为食品检验处。AMC还定义了SubjectGet()，SubjectAdd()，SubjectDel()，ObjectGet()，ObjectAdd()，ObjectDel()方法，分别用于获取、添加、删除主体和对象的属性。

表1 主体、对象的属性

(2)PMC负责存储和管理本文定义的访问策略，与AMC相同，只能由管理员(对象的拥有者)执行。在本文中，访问策略定义为一组主体属性(SA)、一组对象属性(OA)、一组访问能力(Cap)和一组环境上下文(Cxt)的组合，即在环境上下文Cxt下，具有SA属性的主体可以对具有OA属性的对象进行Cap操作。在访问能力Cap中设置了两个参数，第1个true/false代表是否具有该能力，第2个1/0代表是否可以对该能力进行进一步委派。在环境上下文Cxt中设置了一个参数Parm，如果Parm为0则不运用动态访问控制，如果为1则需要再设置开始时间StartTime和结束时间EndTime，表示只有在这段时间内才能访问该对象。表2举例说明了一个访问控制策略，主体属性SA={部门:海关,科室:税务室,职位:主管},对象属性OA={部门:检疫部门,科室:食品检验处},访问能力Cap={Read,Write,Execute,Degelated},环境上下文Cxt={Parm:1,StartTime:1622505600,EndTime:1625043600}。其中StartTime和EndTime为Unix时间戳，代表在北京时间2021年6月1日8时～2021年6月30日17时，海关部门的税务室主管可以对检疫部门食品检验处的信息进行读、写和执行操作，同时可以将这些能力进一步委派给下一个主体。与文献[19]不同的是，由于访问策略不针对某个特定主体或对象，一个策略可以限定多个主体和对象之间的访问控制，这些策略均以表格的形式存储在PMC中，同时该合约中还定义了policyGet()，policyAdd()，policyDelete()，policyUpdate()方法，可以对访问策略进行获取、增加、删除、和修改操作。

表2 访问策略示例

续表2

(3)TGC负责在ACC通过主体的访问请求后，根据访问策略为其生成相应的能力令牌，同时提供了tokenGenerate()方法，用于生成能力令牌。本文参考NAKAMURA等[10]的工作，将传统包含多个操作的能力令牌拆分为单独的能力令牌，能力令牌不再以主体为单位，而是以一个单一的授权能力作为单位，即不像之前的CBAC方案为每个主体颁发一个能力令牌，而是为每一个授权的能力创建一个单独的令牌。能力令牌的结构定义为

CAPSo[IDs][IDo][OP]=

{IDp,{IDCh},Dep,DR}。

(1)

式中：IDs为主体的身份标识；IDo为访问对象的身份标识；OP为一系列操作的集合，如读取、写入、执行等，如果为NULL，则不允许对资源进行操作；IDp为给主体S赋予权限的父主体的身份标识；IDch为主体S赋予权限的子主体的身份标识；Dep为令牌在委托树中的深度；DR表示是否可以进一步委派权限。

以表2为例，如果ACC通过主体的访问请求，TGC则会为该主体生成相应的3个能力令牌，即读(read)能力令牌、写(write)能力令牌和执行(execute)能力令牌。

(4)TMC负责存储和管理主体已经获得的能力令牌。在主体获得其授权的能力令牌后，若访问策略中的委派参数为1，则允许主体进一步委派或撤销其所有能力令牌。该方案具有更细的粒度，能够允许主体委派和撤销某个单一能力，主体间的委派关系以树的数据结构进行存储。PMC提供了tokenGet()，tokenDelegate()方法，用于获取主体已经获得的令牌和主体对自己已拥有令牌的委派，图2所示为3个主体间的委派关系。主体A拥有读、写和执行3个能力令牌，通过委派权限为True可以看出这3个能力均可委派给别的主体，主体A将读和写能力授予主体B，将执行能力授予主体C，同时指定赋予主体B的“读”能力可以进一步委派，而“写”能力不可以进一步委派，赋予主体C的“执行”能力可以进一步委派。读、写和执行能力令牌中的子主体分别变为B，B，C，而且B，C主体中的委派树深度在委派完成后都变为1。

(5)ACC负责响应从主体到对象的访问请求，在本框架中起决定作用。主体对某个对象发起访问请求时，需要将请求信息以事务的形式发送给ACC的accessControl()方法，请求信息包括主体标识、对象标识和操作。当ACC收到该事务后，会从AMC中获取主体和对象属性，再从PMC中查询是否有相应的访问策略。随后，ACC从TMC中查询主体是否已经具有对该对象的能力令牌，若该主体之前就曾获得过访问该对象的能力令牌，则ACC直接通过访问请求；若主体未拥有能力令牌，则ACC基于这些属性、访问策略决定是允许该主体对对象的访问申请，然后将响应结果返回给主体和对象。

2.2 多部门协同访问控制流程建模

本文面向的业务场景主要涉及文件上传和访问控制流程两个过程，本章将对这两个业务过程进行建模。

2.2.1 区块链/IPFS存储数据流程

IPFS与区块链的存储数据流程如图3所示，首先将文件上传到IPFS，再将返回的存储地址哈希值以事务的形式提交到区块链中。

算法1contentaddressedhash。

Require:ImageFiles //网络中节点上传的图片文件

1:file←request.file['upload'] //初始化IPFS

2:api←ipfsapi.connect['localhost',4 200] //存入IPFS的源文件

3:res←api.add(file) //返回二进制编码

4:Hv←convert(file,binary) //创建源文件的二进制索引码

5:digest←ch('sha 256').update(file).digest()

6:Mds←(digest.bytelength.toString(16),'hex') //返回基于内容寻址的哈希值

7:content_addressed←combine(Hv,Mds,digest)

8:return content addressed hash

各部门上传文件到IPFS的执行流程如算法1所示[20]，算法描述如下：文件由网络中的peer节点上传，首先用ipfsapi.connect()方法建立与IPFS的连接，再调用add()方法将图片文件存储到IPFS中，文件将会被切分为碎片，每一个不超过256 kB，用convert()方法将其转换为二进制格式后作为输入进行一次SHA256哈希运算[13]得到一个digest值，将digest值转换为十六进制得到该文件基于内容寻址的哈希值。

2.2.2 访问控制流程

整个访问控制流程中各合约的交互过程如图4所示。首先，主体将对目标对象的访问信息以事务的方式发送给ACC，ACC接收到来自主体的信息后，从AMC中查询并获取主体和对象的属性。接着，ACC从PMC中查询是否有相应的访问策略，否则将禁止访问的结果返回给主体，是则从TMC中查询该主体是否拥有访问对象的能力令牌；如果主体之前就拥有该对象的能力令牌，则将允许访问的结果返回给主体，否则调用TGC为其生成相应的能力令牌。最后，ACC将响应结果返回给主体。访问控制流程如算法2所示。

算法2AccessControlProcess。

Require:Subject_ID,Object_ID,Operations

//访问主体的ID，访问对象的ID以及对访问对象执行的操作

1:AccessRequest←Acc.accessControl(Subject_ID,Object_ID,Operations) //AMC返回主体和对象的属性

2:Subject_attributes←AMC.SubjectGet(Subject_ID)

3:Object_attributes←AMC.ObjectGet(Object_ID) //PMC返回匹配的访问策略

4:AccessControlPolicy←PMC.policyGet(Subject_attributes，Object_attributes)

5:if AccessControlPolicy!=“”

6:Allowed_Capabilities←AccessControlPolicy.Capability

7:end if //查询主体是否拥有访问令牌

8:Subject.token←TMC.tokenGet(Subject_ID)

9:if Subject.token==“”

10:Subject.token←TGC.tokenGenerate(Allowed_Capabilities)

11:end if

12:return Subject.token

主体对对象发起的访问控制流程如算法2所示，算法描述如下：主体首先调用ACC的accessControl()方法，将自身的ID、访问对象的ID、对访问对象进行的操作作为输入，AMC调用SubjectGet()和ObjectGet()方法获取主体与对象的属性，随后调用PMC中的policyGet()方法获取相应的访问策略，如果访问策略不为空，则TMC调用tokenGet()方法查询主体是否之前已经获得过对象的访问能力令牌，如果为空，则调用tokenGenerate()方法为主体生成策略中定义的能力令牌，将结果返回给主体和对象。

算法3TokenDelegationProcess。

Require:SubjectA_ID,SubjectB_ID,CapabilityToken

1:DelegationRequest←TMC.tokenDelegate(SubjectA_ID,SubjectB_ID,CapabilityToken,1,)

//主体A将自己的能力令牌委派给对象B

2:SubjectA.token←TMC.tokenGet(SubjectA_ID)

3:if CapabilityToken==SubjectA.token

4:if SubjectA.token.DelegationRight==1 //主体A的能力令牌是否可以进行委派

5:SubjectB.token←TGC.tokenGenerate(SubjectA.token.Capability)

6: SubjectB.token.Parent←SubjectA_ID

7:SubjectB.token.Dep+=1

8: SubjectB.token.DelegationRight←1

9: end if

10:end if

10:return SubjectB.token

主体间的令牌委派流程如算法3所示，算法描述如下：主体A想将自己的能力令牌CapabilityToken委派给主体B，使其拥有和自己同样的能力。首先主体A调用TMC中的tokenDelegate()方法，将自己的ID、主体B的ID、想要委派的能力令牌、是否允许进一步委派作为输入；然后TMC调用tokenGet()方法查询主体A是否拥有该能力令牌，如果查询结果与A的能力令牌匹配，则为B生成相同的能力令牌，并逐一修改令牌中的参数(父主体Parent、委派深度Dep、进一步委派权限DelegationRight)；最后将能力令牌返回主体B。

3 CABAC实验分析

通过仿真实验对本文所提CABAC框架的有效性进行验证。实验环境如下：操作系统为Ubuntu 18.04.5，CPU为Inter(R) Core(TM) i7-10700 CPU @ 2.90 GHz，内存大小为16 GB，HyperledgerFabric版本为1.4.0，node.js版本为10.13.0，npm版本为6.4.1。测试区块链网络运行在单台主机上，包括两个CA和一个Orderer节点。

3.1 访问控制实例

传统的RABAC模型在访问过程中通过主体和对象属性决定是否允许访问。由于混合了CBAC，相比基于单独机制的访问控制，本文方案在整个访问流程中包含有关能力令牌生成与委派的相关步骤。通过生成细化到单独操作的能力令牌，例如read操作能够以更细粒度限制主体对访问对象进行的操作，同时令权限的分配和管理更加灵活。

本章模拟了一个访问控制过程实例：部门数据管理员将文件上传到IPFS并获取哈希值QmSyzwqkCnp8waXtx7BqUN15DWPAGg9gCWgYeH

n81MnrFK，如图5所示；管理员为主体A添加主体属性，如图6所示；主体A对对象B发起访问请求，获得能力令牌并将该能力令牌委派给主体C。首先，ACC调用TGC中的tokenGeneration()ABI后，根据PMC中的访问策略为主体生成相应的能力令牌。图7所示为主体A的“read”能力令牌，该令牌表明主体A可以对对象B进行read操作，因为是新生成的令牌，所以没有父主体，也没有子主体，相应地在委派树中的深度也为0。DelegationRight表明主体A可以将该令牌进行进一步委派。与NAKAMURA等[10]的方案不同的是，本文方案默认所有能力令牌的委派均可撤回。

主体A将该“read”能力令牌委派给主体C后，能力令牌的信息如图8所示。可见Depth从0变成1，表示该令牌在委派树中的深度为1，即有过一次委派关系。

最终ACC会返回访问请求信息，如图9所示。ACC通过与其他几个合约交互验证了主体A和对象B的属性，并根据匹配的访问策略赋予主体A“read”能力令牌，同时指定该“read”令牌可进一步委派。

3.2 区块链网络性能

3.2.1 存储空间性能

本文使用的数据为云南省各口岸班车运营数据，包括20万条记录。

存储空间压缩比

(2)

式中：H为区块链中每个区块头数据量的大小；iHash为事务在IPFS中的哈希值；N为区块链中事务的数量；Tx为区块链中每个事物的数据量。区块头为80 B，每个区块平均包括500个交易，每个交易约为250 B。IPFS返回的哈希值只占46 B。由公式可以推出随着交易数量的增加，数据的压缩比明显增加。图10和图11所示分别为数据压缩比随数据量的变化，以及区块链直接存储数据和存储IPFS文件哈希值的数据量对比。可见，随着数据量的增大，源数据与返回哈希值的占用存储空间比越大，用IPFS进行链下存储的优势越明显。

3.2.2 访问控制流程性能

本文方案与其他文献方案在访问控制流程中的功能比较如表3所示。

表3 访问控制方案对比

由表3可见，ABAC[9]访问控制方案在区块链网络中将节点分为授权节点AN和公共节点，当公共节点发起访问请求时，授权节点AN将调用链码记录信息并响应访问请求。AN不仅为物联网设备分配属性，还对访问策略进行制定和决策，其通过查询部署过的链码检索已经注册的访问凭证，来验证请求者的身份和访问策略的有效性；CBAC[10]通过将单独的能力作为基本单位定义能力令牌，将传统的能力令牌划分为多个单独的能力令牌，实现了更细粒度的访问控制和更灵活的令牌管理。本文方案结合ABAC和CBAC，既可指定访问策略，也可划分能力令牌，还能支持区块链数据以链下方式存储。

在不同操作下，CABAC方案中不同操作的平均耗时如图12所示，其中横轴坐标表示操作名称，纵轴坐标表示平均耗时(单位：ms)。可见，本文方案中所有操作消耗的时间均在450 ms之内，相比获取属性和委派能力令牌操作，生成能力令牌操作和最后的返回访问结果操作需要花费更多的时间，但总体上可以接受。

4 结束语

为了实现部门与部门间的细粒度访问控制，本文提出一种基于区块链的多部门数据共享混合访问控制方案，使用HyperledgerFabric联盟链作为区块链基础架构，通过编写链码进行访问控制和权限的委派，同时利用IPFS以链下存储的方式拓展区块链的可存储性，减轻了区块链的数据存储压力，最后通过仿真实验验证了该方案的可行性。与现有基于区块链的访问控制方案相比，本文提出混合基于属性和能力的访问控制模型的数据共享访问控制方案，能够在实施访问控制的前提下，以更细的粒度进行访问能力的生成与委派。然而，本文方案未涉及基于属性文件的加密，在数据安全性上有待提升。此外，在本文提出的令牌委派过程中，尚未对委派对象设置限制，容易出现随意委派能力令牌的情况。这是未来进一步研究的内容。