CN115618321A - 访问控制方法及装置、电子设备、存储介质 - Google Patents

Abstract

本申请公开了一种访问控制方法及装置、设备、存储介质，该方法包括：通过区块链的访问管理合约接收第一用户对第一文件的访问请求；基于所述第一文件对应的第一属性策略，通过所述访问管理合约调用所述区块链的属性子链确定所述第一用户的属性信息；基于所述身份标识，通过所述访问管理合约调用所述区块链的身份子链确定所述第一用户的身份信息；通过所述访问管理合约验证所述第一用户的属性信息和所述身份信息；在所述第一用户通过验证的情况下，通过所述区块链的文件访问合约向所述第一用户授权。本申请实施例采用多链结构，使用了属性策略与身份认证结合的方式来对数据请求者进行授权，确保安全可追溯的安全验证。

Description

访问控制方法及装置、电子设备、存储介质

技术领域

本申请涉及电子设备技术领域，涉及但不限定于访问控制方法及装置、电子设备、存储介质。

背景技术

基于用户、资源、操作和运行上下文属性所提出的基于属性策略的访问控制(Attribute-base Access control，ABAC)将主体和客体的属性作为基本的决策要素，灵活利用请求者所具有的属性集合决定是否赋予其访问权限，能够很好地将策略管理和权限判定相分离。由于属性是主体和客体内在固有的，不需要手工分配，同时访问控制是多对多的方式，使得ABAC管理上相对简单。并且属性可以多个角度对实体进行描述，因此可根据实际情况改变策略。

然而各方机构的身份、属性信息的分布具有分散性，例如医院拥有医生患者的身份信息，而金融机构拥有着用户的财产状况的属性信息，因此，区块链平台集中验证时，无法从数据孤岛中实现统一的用户访问控制。

发明内容

本申请提供一种访问控制方法及装置、电子设备、存储介质，至少解决了相关技术中区块链平台集中验证时安全可追溯的安全验证，无法从数据孤岛中实现统一的用户访问控制的问题。

本申请的技术方案是这样实现的：

第一方面，本申请提供一种访问控制方法，应用于区块链，所述方法包括：

通过所述区块链的访问管理合约接收第一用户对第一文件的访问请求；所述访问请求中包括所述用户的身份标识；

基于所述第一文件对应的第一属性策略，通过所述访问管理合约调用所述区块链的属性子链确定所述第一用户的属性信息；所述属性子链为用于对用户属性信息进行管理的私有链；

基于所述身份标识，通过所述访问管理合约调用所述区块链的身份子链确定所述第一用户的身份信息；所述身份子链为用于存储身份认证记录的私有链；

通过所述访问管理合约验证所述第一用户的属性信息和所述身份信息；

在所述第一用户通过验证的情况下，通过所述区块链的文件访问合约向所述第一用户授权。

第二方面，本申请提供一种访问控制装置，包括：

第一接收模块，用于通过所述区块链的访问管理合约接收第一用户对第一文件的访问请求；所述访问请求中包括所述第一用户的身份标识；

第一确定模块，用于基于所述第一文件对应的第一属性策略，通过所述访问管理合约调用所述区块链的属性子链确定所述第一用户的属性信息；所述属性子链为用于对用户属性信息进行管理的私有链；

第二确定模块，用于基于所述身份标识，通过所述访问管理合约调用所述区块链的身份子链确定所述第一用户的身份信息；所述身份子链为用于存储身份认证记录的私有链；

属性验证模块，用于通过所述访问管理合约验证所述第一用户的属性信息和所述身份信息；

授权模块，用于在所述第一用户通过验证的情况下，通过所述区块链的文件访问合约向所述第一用户授权。

第三方面，本申请提供一种电子设备，包括存储器和处理器，所述存储器存储有可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述访问控制方法中的步骤。

第四方面，本申请提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述访问控制方法中的步骤。

本申请提供的技术方案带来的有益效果至少包括：

在本申请实施例中，当用户向区块链请求文件访问权限时，通过区块链上的访问管理合约分别从属性子链和身份子链中获取属性信息和身份信息进行属性验证，并通知文件访问合约属性验证成功，由文件访问合约向用户授权。本申请实施例采用了多链结构，由属性子链存储属性策略与文件之间的映射关系，由身份子链实现身份管理映射(由身份验证服务者提供)，实现了可拓展的属性分配，确保安全可追溯的安全验证。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图，其中：

图1A为相关技术中基于CP-ABE算法的区块链数据访问控制方案的系统框架；

图1B为相关技术基于CP-ABE算法的区块链数据访问控制方案的流程示意图；

图2为本申请实施例提供的一种访问控制方法的流程示意图；

图3为本申请实施例提供的一种访问控制方法的流程示意图；

图4为本申请实施例提供的一种访问控制方法的流程示意图；

图5为本申请实施例提供的一种访问控制方法的流程示意图；

图6为本申请实施例提供的访问控制方法的整体框图；

图7为本申请实施例提供的一种访问控制装置的组成结构示意图；

图8为本申请实施例提供的一种电子设备的硬件实体示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。以下实施例用于说明本申请，但不用来限制本申请的范围。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。

需要指出，本申请实施例所涉及的术语“第一\第二\第三”仅仅是是区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一\第二\第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。

本技术领域技术人员可以理解，除非另外定义，这里使用的所有术语(包括技术术语和科学术语)，具有与本申请实施例所属领域中的普通技术人员的一般理解相同的意义。还应该理解的是，诸如通用字典中定义的那些术语，应该被理解为具有与现有技术的上下文中的意义一致的意义，并且除非像这里一样被特定定义，否则不会用理想化或过于正式的含义来解释。

区块链：作为一个信息技术领域的术语，区块链是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。区块链是比特币的一个重要概念，它本质上是一个去中心化的数据库，同时作为比特币的底层技术，是一串使用密码学方法相关联产生的数据块，相当于账本的内容。区块链是一个分散数据库，每个节点数据(或行为)都被其他人记录，所以区块链上的每个人的数据(或行为)都可以被追踪和还原。根据系统控制权和交易信息公开与否进行归类，区块链可以分为公有(如比特币、以太坊等)、私有链和联盟链(如超级账本等)三类。

事件：即区块链上的订阅或发行事件。

交易：为账本上的执行单元。

预言机：是区块链行业的基础设施之一，是将区块链外信息写入区块链内的机制。发生在区块链外部的事件、数据、支付消息等都可以通过预言机写入到区块链上的智能合约中，扩大了智能合约的应用场景。

智能合约(Smart Contract)：是一种旨在以信息化方式传播、验证或执行合同的计算机协议。智能合约是各种商业规则的集合，它在区块链上运行，由一组利益相关方共有并进行验证。智能合约在商业自动化进程中非常管用，而且诚信可靠，它能够使利益相关方以团体形式处理并验证合约条款。超级账本(Hyperledger)就是采用链上代码(chaincode)执行智能合约的，也就是说，智能合约中所有相关条款都由代码编成，能够进行自动结算，今后通过签名或其他触发事件来执行。

星际文件系统(Inter-Planetary File System，IPFS)是一种点对点(Point toPoint，P2P)的分布式文件系统，目标是为了补充(甚至是取代)目前统治互联网的超文本传输协议(Hypertext Transfer Protocol，HTTP)，将所有具有相同文件系统的计算设备连接在一起。

基于用户、资源、操作和运行上下文属性所提出的基于属性策略的访问控制(Attribute-base Access control，ABAC)将主体和客体的属性作为基本的决策要素，灵活利用请求者所具有的属性集合决定是否赋予其访问权限，能够很好地将策略管理和权限判定相分离。

由于属性是主体和客体内在固有的，不需要手工分配，同时访问控制是多对多的方式，使得ABAC管理上相对简单。并且属性可以多个角度对实体进行描述，因此可根据实际情况改变策略。

例如针对时间约束所提出的基于时态特性的访问控制模型通过分析用户在不同的时间可能有不同的身份，将时态约束引入访问控制系统中，通过时间属性来约束用户的访问操作；又比如基于使用的访问控制模型(Usage Control，UCON)引入了执行访问控制所必须满足的约束条件(如系统负载、访问时间限制等)。除此之外，ABAC的强扩展性使其可以同加密机制等数据隐私保护机制相结合，在实现细粒度访问控制的基础上，保证用户数据不会被分析及泄漏。例如，基于属性的加密(Attribute-based Encryption，ABE)方法。

相关技术中提出了一种密文策略属性基加密(CP-ABE，Ciphertext PolicyAttribute-based Encryption)算法的区块链数据访问控制方案。结合超级账本中原有的用户证书管理机构(Fabric-CA)模块，用于解决联盟链超级账本中存在的数据隐私安全问题，该方案在实现用户级细粒度安全访问控制区块链数据的同时，还能够实现对CP-ABE方案中用户属性密钥的安全分发。对该方案进行的安全分析表明，该方案实现了ABE用户属性私钥安全分发和数据隐私性保护的安全性目标，性能分析部分也说明了所提方案具有良好的可用性。

在CP-ABE算法中，解密策略在加密时被嵌入密文中，而用户的属性则在密钥生成时被嵌入其私钥中，即访问策略与密文相关联。基于CP-ABE算法的区块链数据访问控制方案的系统框架如图1A所示，该方案包括区块链网络(Fabric)11、证书颁发机构(Fabric-CA)12和客户端(Client)13三部分，该方案基于现有的区块链网络11和证书颁发机构12，可通过在证书颁发机构12中嵌入CP-ABE算法实现，即相当于证书颁发机构12作为CP-ABE方案中的可信第三方，此时证书颁发机构12不仅管理着原有区块链网络11中用户所需的证书即实现用户证书管理121，同时具有CP-ABE系统初始化122和用户属性私钥生成与分发123。用户通过客户端(Client)13实现与区块链网络11和证书颁发机构12的交互，客户端13中实现发起交易131、用户证书接收132、用户属性私钥接收133、CP-APE数据加解密134，区块链网络11中实现交易背书111、交易排序112、交易验证及上链113等功能。

在实施中，用户向证书颁发机构12登记注册以获得对应的证书和CP-ABE方案的用户属性私钥，利用获取到的私钥与用户指定的访问控制策略对明文数据进行加密，再通过交易的形式将密文发送至区块链网络11中进行加密数据的上链存储。

为了能够更加客观地展示该方案的实施流程，如图1B所示，以客户端13A即用户A对应的客户端和客户端13B即用户B之间的交互为例，用户A想要将隐私数据加密上链，用户B希望能够访问到密文对应的明文，假设用户A通过客户端13A、用户B通过客户端13B与区块链网络11和证书颁发机构12进行交互，包括建立(Setup)、注册(KeyGen)、加密(Encrypt)、更新(Update)、下载(Download)和解密(Decrypt)等步骤。该过程的主要实现步骤如图1B所示，该方案的整体工作流程大致可分为3个阶段：

密钥生成阶段21，该阶段包括以下步骤：

步骤S1，证书颁发机构12生成CP-ABE方案中的主密钥(MK)和公开参数(PK)；

步骤S2A，客户端13A向证书办法机构12发送第一用户证书请求；

步骤S2B，客户端13B向证书办法机构12发送第二用户证书请求；

步骤S3A，证书颁发机构12根据第一用户证书请求生成用户证书(U_certA)和属性密钥密文(CT_SKA)并返回给客户端13A；

步骤S3B，证书颁发机构12根据第二用户证书请求生成用户证书(U_certB)和属性密钥密文(CT_SKB)返回给客户端13B；

数据加密上链阶段22，该阶段包括以下步骤：

步骤S4，客户端13A制定访问控制策略，并根据访问控制策略构造访问树；通过输入公开参数、上链隐私数据明文以及访问树，生成交易密文(CTA)；

步骤S5，客户端13A将交易密文作为交易的负载发往区块链网络11进行加密交易的背书、排序、分发和验证操作，最终将交易密文成功上链；

问控制阶段23：包括

步骤S6，客户端13B向区块链网络11查询交易密文的交易信息；

步骤S7，区块链网络11向客户端13B发送交易信息对应的交易密文；

步骤S8，客户端13B使用用户私钥将属性密文进行解密，生成明文属性密钥(SKB)；在明文属性密钥中包含的属性满足交易密文中包含的访问控制策略的情况下，客户端13B对加密数据进行解密，生成隐私数据明文。

上述基于CP-ABE区块链数据访问控制方案还存在以下问题：

1)CP-ABE算法的解密过程涉及复杂的运算，和客户端的计算能力受限相矛盾。基于密文的访问策略的CP-ABE算法，时间消耗大，计算资源消耗大，不适用于实际应用的区块链上的文件存储；特别是在属性数量增多时，加解密时间都会急剧上升。

2)基于密钥的属性策略访问控制方案难以撤销密钥以实现动态调整。目前大多数基于属性加密方案的构造中没有考虑属性和用户的撤销以及外包解密等问题，而实际的应用场景中往往会面临用户权限变更和撤销等现象，不可避免地会发生属性撤销和密文更新问题。

3)仅支持超级账本，不适用于当前异构区块链的实际场景。虽然超级账本具有非常广泛的应用，但是根据当前的行业应用，机构、企业根据场景需求不同采用了多种不同的区块链平台。因此，考虑具有广泛适用性的支持异构区块链的访问控制策略是非常必要的。

4)仅支持属性策略而没有对应的身份验证。各方机构的身份、属性信息的分布具有分散性，例如医院拥有医生患者的身份信息，而金融机构拥有着用户的财产状况的属性信息，因此，区块链平台集中验证时，无法从数据孤岛中实现统一的用户访问控制。

本申请实施例提供一种访问控制方法，应用于电子设备。所述电子设备包括但不限于手机、笔记本电脑、平板电脑和掌上上网设备、多媒体设备、流媒体设备、移动互联网设备、可穿戴设备或其他类型的电子设备。该方法所实现的功能可以通过电子设备中的处理器调用程序代码来实现，当然程序代码可以保存在计算机存储介质中，可见，该电子设备至少包括处理器和存储介质。处理器可以用于进行访问控制过程的处理，存储器可以用于存储进行访问控制过程中需要的数据以及产生的数据。

图2为本申请实施例提供的一种访问控制方法的流程示意图，如图2所示，所述方法至少包括以下步骤：

步骤S210，通过所述区块链的访问管理合约接收第一用户对第一文件的访问请求；

这里，所述访问管理合约(Access Manager Contract)为区块链上的一种智能合约，用于对请求访问文件的用户权限进行验证，在实施中具体表现为按照文件对应的属性策略。

所述访问请求中包括所述第一用户的身份标识，例如该用户所在学院的学号、该用户所在医院的工号或者身份证号等标识。

步骤S220，基于所述第一文件对应的第一属性策略，通过所述访问管理合约调用所述区块链的属性子链确定所述第一用户的属性信息；

这里，所述属性子链(Attribute Chain，A-Chain)为用于对用户的属性信息进行管理的私有链，该属性子链中维护了一张存储属性策略与文件哈希之间对应关系的哈希属性映射表，以便属性策略更新之后重新加密。其中，哈希属性映射表中包括文件名、文件哈希值和对应的属性策略。

用户请求访问文件时，先通过访问请求将自己需要访问的第一文件和自己的身份标识提交给区块链的访问管理合约，该访问管理合约从预先存储的哈希属性映射表中找到第一文件对应的第一属性策略，并从属性子链中查到到该第一属性策略对应的用户属性信息。其中，用户属性信息可以为该用户注册区块链时登记保存的个人资料，例如针对某个医院区块链平台，用户属性信息为医生所在科室、擅长领域等。

步骤S230，基于所述身份标识，通过所述访问管理合约调用所述区块链的身份子链确定所述第一用户的身份信息；

这里，所述身份子链(Identity Chain，I-Chain)为用于存储用户的身份认证记录的私有链，所有经过各个机构、部门的身份认证之后都会把认证记录记录在身份子链上。

身份子链中预先设定了基于欧洲电子签名及信任体系(electronicIDentification and Authentication Services，eIDAS)的方法和身份验证过程，访问管理合约基于用户请求文件访问权限时提交的身份标识，调用身份子链也就是从提供身份验证的服务机构获取有关数字身份的信息，例如标题、许可证、资格、年龄等，从而确定用户的身份信息。

值得注意的是，该步骤可能会涉及用户的隐私问题，身份子链可以第三方(银行、医院等机构)或政府部门私有，通过外部接口来确认属性，而不直接公开身份子链。

通过步骤S220和步骤S230，可以看出本申请实施例提供的基于属性处理的访问控制方案中，属性策略由文件平台方维护，身份策略由第三方服务者提供，适用于用户数量多的场景；同时，将身份验证与属性策略分离，系统安全性更强。

步骤S240，通过所述访问管理合约验证所述第一用户的属性信息和所述身份信息；

这里，访问管理合约获取该用户所有的属性验证信息进行验证，并在验证成功时发送授权消息给区块链的文件访问合约。

步骤S250，在所述第一用户通过验证的情况下，通过所述区块链的文件访问合约向所述第一用户授权。

这里，所述文件访问合约(Access File Contract)用于在属性验证成功时授予用户第一属性策略对应的密钥，从而用户可以基于该密钥解密要访问的第一文件。

文件访问合约收到属性验证成功的授权消息，调用预言机(Oracle)检查访问管理合约先前验证步骤的总体有效性。如果检查成功，则文件访问合约会发出一个交易，并将交易上链，确认验证完成。

在本申请实施例中，当用户向区块链请求文件访问权限时，通过区块链上的访问管理合约分别从属性子链和身份子链中获取属性信息和身份信息进行属性验证，并通知文件访问合约属性验证成功，由文件访问合约向用户授权。本申请实施例采用了多链结构，由属性子链存储属性策略与密钥之间的映射关系，由身份子链实现身份管理映射(由身份验证服务者提供)，实现了可拓展的属性分配，相比于传统的属性加密方法在动态更新方面更加友好。

图3为本申请实施例提供的一种访问控制方法的流程示意图，如图3所示，所述方法还包括以下步骤：

步骤S310，通过所述区块链的访问管理合约接收第一用户对第一文件的访问请求；

这里，所述第一文件存储在分布式文件系统如IPFS，所述访问请求中包括所述用户的身份标识。

本申请实施例考虑到区块链的存储开销，拟使用区块链做文件共享平台，同时使用IPFS作为文件存储平台来减少区块链的时间开销和计算代价。在实施中，将待共享的文件存储在IPFS中，同时区块链记录IPFS中文件哈希值，节约区块链存储空间，并且提高了区块链吞吐量，在同样的块生成速度下，可以处理更多交易。另外，IPFS的点对点特性和分布式哈希表的特性使得存储空间利用更加合理。

步骤S320，所述访问管理合约获取所述第一文件在所述分布式文件系统的哈希值；

这里，所述区块链的属性子链中记录了IPFS中文件名、哈希值、发布者等信息，可以通过访问管理合约调用属性子链，从属性子链中查找到第一文件的哈希值。

步骤S330，所述访问管理合约基于所述第一文件的哈希值，从预设的哈希属性映射表中，确定所述第一文件对应的第一属性策略；

这里，所述属性子链中维护了预设的哈希属性映射表，所述哈希属性映射表用于记录文件哈希值与属性策略之间对应关系。

步骤S340，基于所述第一文件对应的第一属性策略，通过所述访问管理合约调用所述区块链的属性子链确定所述第一用户的属性信息；

这里，所述属性子链为用于对用户的属性信息进行管理的私有链。属性子链中存放有每个类别文件对应的属性策略，以及属性策略对应的用户的具体属性信息。

在所述属性子链中维护了所述哈希属性映射表，在一些实施方式中，为文件A生成符合XACML(可扩展访问控制标记语言)标准的文件用来规定新的属性策略，并将新的属性策略更新至所述哈希属性映射表中；在另一些实施方式中，可以基于哈希属性映射表，查找文件B对应的属性策略。

步骤S350，在所述属性子链中存在所述第一用户的属性信息的情况下，通过所述访问管理合约转发所述访问请求至所述区块链的身份子链；

这里，所述身份子链为用于存储用户的身份认证记录的私有链。

所述访问管理合约首先验证属性子链中存储的用户属性信息，通过

步骤S360，基于所述身份标识，通过所述身份子链确定所述第一用户的身份信息；

步骤S370，通过所述访问管理合约验证所述第一用户的属性信息和所述身份信息；

步骤S380，在所述第一用户通过验证的情况下，通过所述区块链的文件访问合约向所述第一用户授权。

这里，属性验证成功之后，访问管理合约收到授权消息，并验证授权操作过程的有效性，即可以向用户授权，也就是从属性子链中提取出第一属性策略对应的密钥给用户，用户利用密钥即可解密第一文件进行访问。

同时，访问管理交易会发出一个交易，并将交易上链。发布交易并上链的过程可以通过以下步骤实现:

步骤S3801，在所述第一用户通过验证的情况下，通过所述文件访问合约确定所述第一属性策略对应的第一密钥；

这里，所述第一密钥用于对所述第一文件对应的密文进行解密。也就是说，第一文件是以密文的形式存储在IPFS中，且属性子链中存储了第一文件的第一属性策略以及形成该密文时对应的第一密钥，从而属性策略与密钥是一一对应的。

步骤S3802，通过所述文件访问合约以所述第一用户的公钥加密所述第一密钥，得到第二密钥；

这里，使用用户的公钥加密第一密钥得到第二密钥，可以使得该用户成为唯一可以使用自己的私钥解密第二密钥的人。

步骤S3803，通过所述文件访问合约以所述第二密钥作为输入发起交易请求并将所述交易请求提交至所述属性子链，以实现对所述第一用户的授权。

这里，所述第二密钥用于所述用户以自己的私钥进行解密得到所述第一密钥。在用户解密了第一密钥之后，可以进一步使用第一密钥对第一文件对应的密文进行解密，从而得到第一文件的明文文件。

在本申请实施例中，当用户向区块链请求文件访问权限时，通过区块链上的访问管理合约分别从属性子链和身份子链中获取属性信息和身份信息进行属性验证，在属性验证通过之后通过文件访问合约从属性子链中提取出对应属性策略的密钥给用户，用户即可解密文件进行访问。本申请实施例采用私有链来存储属性策略和身份策略，保证属性策略的安全性、隐私性。支持海量用户接入，并且使密钥访问可追溯、可监管。同时文件发布和访问分别使用文件访问合约和访问管理合约这两个智能合约，其中文件访问合约可以针对先前操作进行验证，进一步保证了数据机密性。

图4为本申请实施例提供的一种访问控制方法的流程示意图，如图4所示，该方法至少包括以下步骤：

步骤S410，响应于接收到存储第二文件的存储请求，通过所述区块链的存储管理合约对所述第二文件进行加密，得到所述第二文件对应的密文；

这里，所述存储管理合约(Store Manager Contract)为所述区块链上的智能合约，用于对存储的文件进行加密，并负责为文件添加属性策略。

在用户发出存储文件请求之后，存储管理合约需要将待存储文件与对应的属性策略关联。从而使用属性策略需要的密钥对第二文件进行加密，得到第二文件对应的密文即加密文件。

可以通过以下步骤实现待存储的第二文件的加密过程：

步骤S4101，通过所述存储管理合约从所述属性子链中查找所述第二文件对应的第二属性策略；

这里，所述属性子链中存放有每个类别文件对应的属性策略。在实施中，可以基于属性子链中的哈希属性映射表，找到该第二文件的哈希值对应的第二属性策略。

步骤S4102，通过所述存储管理合约确定所述第二属性策略对应的第三密钥；

这里，所述存储管理合约在查询第二文件对应的第二属性策略时，同时可以从属性子链中取出该第二属性策略需要的第三密钥。

步骤S4103，通过所述存储管理合约以所述第三密钥对所述第二文件进行加密，得到所述第二文件对应的密文。

这里，利用与文件匹配的属性策略的密钥对文件进行加密运用的是对称加密技术，例如高级加密标准(Advanced Encryption Standard，AES)。

相比于相关技术中基于密文的访问策略的CP-ABE算法时间消耗大，计算资源消耗大，不适用于实际应用的区块链上的文件存储；本申请实施例提供的基于属性策略的访问控制方案使用对称加密技术对共享数据文件如第二文件进行加密，可以节约访问控制的时间开销，进一步适应多个不同的验证实体的实际应用。

在一些实施例中，所述属性子链中还未存储所述第二文件对于文件类别的属性策略，需要存储管理合约生成符合XACML标准的文件用来规定策略。同时将第二文件发布在分布式文件系统上，在获得对于哈希值之后作为一次交易加入属性子链中，在实施中可以通过以下步骤实现：

步骤S4104，所述存储管理合约在所述属性子链中未查找到所述第二文件对应的第二属性策略的情况下，生成新的第二属性策略；

这里，在下一次存储同类别的第二文件时，可以将本次生成的属性策略作为上文提到的第二属性策略。

步骤S4105，所述存储管理合约将所述新的第二属性策略与所述第二文件关联，得到关联关系；

步骤S4106，所述存储管理合约将所述关联关系存储在所述属性子链的哈希属性映射表中。

这里，在每次生成新的第二属性策略之后，存储管理合约都将该过程作为一次交易，并记录在属性子链中。

步骤S420，通过所述区块链的文件存储合约执行发布文件操作将所述密文发布在所述分布式文件系统上；

这里，所述文件存储合约(Store File Contract)为区块链上用于存储文件的智能合约，在实施中可以将文件发布到分布式文件系统如IPFS上，并把IPFS上的对应文件哈希记录在区块链上。

所述分布式文件系统用于存储所述密文并确定所述密文的哈希，这样通过使用分布式文件系统作为文件存储平台来减少区块链的时间开销和计算代价。

步骤S430，通过所述文件存储合约将所述发布文件操作作为一次交易记录在所述区块链中。

这里，文件存储合约将第二文件在分布式文件系统上发布，发布文件操作视为一次交易存放在区块链上，同时在属性子链的哈希属性映射表中记了第二文件的哈希值、发布者等信息，以便下一次利用所生成的新的第二属性策略对同类别的其他文件进行加密。

在本申请实施例中，首先，响应于接收到存储第二文件的存储请求，通过所述区块链的存储管理合约对所述第二文件进行加密，得到所述第二文件对应的密文；然后，通过所述区块链的文件存储合约执行发布文件操作将所述密文发布在所述分布式文件系统上；最后通过所述文件存储合约将发布文件操作作为一次交易记录在所述区块链中。本申请实施例通过使用对称加密技术对共享数据文件加密，并通过两条私有链，实现身份和属性策略的同时，可以安全可追溯的安全验证，也比原方案具有更好的拓展性。

图5为本申请实施例提供的一种访问控制方法的流程示意图，如图5所示，该方法至少包括以下步骤：

步骤S510，在所述属性子链的参与方申请改变所述属性子链中的第三属性策略的情况下，通过所述访问管理合约验证所述参与方的身份；

这里，所述属性子链的参与方表示向区块链注册登记过的所有用户。

所述第三属性策略为所述属性子链中的任一属性策略，可以与第一属性策略、第二属性策略中的至少一个相同，也可以与第一属性策略、第二属性策略均不同。应理解，不同类别文件的属性策略不同。

所述访问管理合约验证参与方的身份的过程可以参见步骤S120至步骤S140的描述。

步骤S511，在参与方的身份验证通过的情况下，通过所述存储管理合约将改变后的所述第三属性策略发布至所述属性子链；

这里，存储管理合约将改变后的第三属性策略更新至属性子链中的哈希属性映射表，便于后续基于该哈希属性映射表对相应文件进行加密。

步骤S512，通过所述存储管理合约生成与改变后的所述第三属性策略对应的第四密钥并存储至所述属性子链；

在一些实施方式中，为了防止其他参与方看到密钥，所以使用区块链的公钥加密，只有区块链可以获取真正的密钥。可以通过以下方式实现步骤S513：通过所述存储管理合约以所述区块链的公钥加密所述第四密钥，得到第五密钥；通过所述存储管理合约将所述第五密钥存储至所述属性子链。

步骤S513，在所述属性子链和所述区块链处于更新属性策略状态的情况下，通过所述从链的访问管理合约接收第二用户的文件访问请求；

这里，所述更新属性策略状态表明所述属性子链的参与方申请改变所述属性子链中的任一属性策略。

步骤S514，响应于所述文件访问请求，所述区块链生成具有相同结构的从链；

这里，区块链和从链具有相同的结构，从链平行于区块链。在区块链为保证前向撤销要求而进行的密钥更新的同时，从链可以通过访问管理合约访问属性子链，从而实现当前请求可以依据最新的属性策略进行验证。

步骤S515，在所述第二用户通过验证的情况下，通过所述从链的文件访问合约将所述文件访问请求作为一个交易发布在所述从链上；

这里，通过所述从链的访问管理合约验证所述第二用户并处理所述文件访问请求；通过所述从链的文件访问合约记录所述从链上的交易，并发布在从链上。

步骤S516，在所述区块链退出所述更新属性策略状态的情况下，将所述从链上的交易合并至所述区块链。

这里，待区块链更新完成，从链上的交易与区块链合并，由于考虑到在一个从链的生命周期中区块链可能有多次属性更新，因此合并交易时需要验证属性策略是否符合当前最新的属性策略。

在一些实施方式中，通过所述区块链的文件存储合约查看所述属性子链上的交易，确定至少一个变化的属性策略；通过所述文件存储合约从所述哈希属性映射表中确定所述至少一个变化的属性策略对应的文件；通过所述存储管理合约以所述第四密钥对所述至少一个变化的属性策略对应的文件进行重新加密。

区块链的文件存储合约查看属性子链上的交易，找出对应修改(增加、更新、删除)的属性策略，并根据文件-属性映射表对被修改属性对应的文件使用新的密钥进行重新加密。由于用户量巨大，无法实时每个用户的属性变化，因此属性子链在固定时间之后将会自动更新更换属性策略对应的密钥，来保证用户之前获取的密钥无效，从而通更新密钥实现可动态撤销属性的访问控制。

下面结合一个具体实施例对上述访问控制方法进行说明，然而值得注意的是，该具体实施例仅是为了更好地说明本申请，并不构成对本申请的不当限定。

考虑到灵活利用请求者所具有的属性集合决定是否赋予其访问权限，本申请实施例采用基于属性策略的访问控制方案。同时，为了节约访问控制的时间开销，在实现基于属性策略的访问控制的同时，进一步适应多个不同的验证实体的实际应用，采用从链结构和对称加密的技术。本申请使用对称加密对共享数据文件加密，并通过两条私有链实现身份和属性策略，可以实现安全可追溯的安全验证，具有更好的拓展性。最后，考虑到区块链的存储开销，拟使用区块链做文件共享平台，同时使用IPFS作为文件存储平台来减少区块链的时间开销和计算代价。

如图6所示，本申请实施例定义以下实体：参与方601(即用户)、身份子链602、属性子链603、文件604、存储管理合约605、文件存储合约606、访问管理合约607、文件访问合约608、IPFS 609、区块链610、从链(Sidechain)611，其中：

参与方601，为请求访问的用户；

身份子链602，为用于身份验证的私有链，所有经过各个机构、部门的身份认证之后都会把认证记录记录在身份子链602上；

属性子链603，为用于属性管理和验证的私有链，由文件共享平台方和相关机构共同维护；

文件604，为需要共享的各种类型的文件(如医疗病例、工业数据等)；

存储管理合约605，负责对文档进行加密，负责添加属性策略；

文件存储合约606，为用于存储文件的智能合约，发布到IPFS 609上，并把对应文件哈希记录在属性子链上；

访问管理合约607，用于对用户访问文件的验证和授权，也就是说验证属性策略；

文件访问合约608，在验证成功时授予相应用户解密文件的密钥k；

哈希-属性映射表，记录文件哈希与属性策略之间的映射关系，包括文件名、IPFS文件哈希(hi)和对应的属性策略p，用户可以在区块链浏览器中看到所有的文件名、IPFS文件哈希和属性策略；

IPFS 609，用于以分布式方式存储数据；

区块链610，即主链，可以是以太坊(Ethereum)、超级账本等支持智能合约的区块链；

从链611(Sidechain)，附着区块链610上成为能与主链进行信息交互的从链，在属性子链603与区块链610进行属性策略更新的过程中，用户可以向从链611发起交易请求，这样保证主链在更新时可以使用原有备份正常交易。

本申请实施例通过多区块链结构和IPFS实现文件存储、访问和属性策略更新三个功能。

在一些实施方式中，通过以下过程实现文件存储：

步骤S621，通过存储管理合约确定待存储文件对应的属性策略；

当用户发出存储文件请求之后，存储管理合约将文档fi与策略p相关联(查询属性子链，属性子链中存放有每个类别不同的策略查找对应文件类别的属性策略)。如果p不存在，则存储管理合约将生成符合XACML标准的文件用来规定策略。在每次生成新的策略之后，存储管理合约都将新的属性策略作为一次交易发布在属性子链603中。

步骤S622，基于属性策略需要的密钥，对待存储文件进行加密，得到密文；

存储管理合约在查询fi对应策略p时，同时可以从属性子链中取出对应策略需要的密钥pk(p与pk是一一对应的)，然后使用对称加密功能(例如AES)对fi进行加密，获得加密文档即密文ei。

步骤S623，通过文件存储合约将密文上传至IPFS网络；

文件存储合约在获得密文ei之后，上传至IPFS网络，获取对应的文件哈希记录hi。

在本申请实施例中，用户需要存放文件时，通过存储管理合约智能合约提交文件进行加密(从属性子链中找到该文件哈希对应属性策略的密钥)；随后，存储管理合约将加密文件交给文件存储合约；文件存储合约在IPFS上发布，发布文件操作视为一次交易存放在区块链610上，同时记录文件哈希、发布者等信息，并维护哈希-属性映射表，以便属性策略更新之后重新加密。

在一些实施方式中，通过以下过程实现文件访问：

步骤S631，用户向访问管理合约发出文件访问请求；

该文件访问请求中包括要访问的文件名、自己的身份标识以及访问所需文件要求的属性信息。

步骤S632，访问管理合约将文件访问请求转发到身份子链，并基于从身份子链获取的身份信息去属性子链获取属性验证信息；

当用户向访问管理合约请求文件访问权限时，属性子链与身份子链与中预先设定了基于欧洲电子签名及信任体系(eIDAS)的方法和身份验证过程，从提供身份验证的服务机构获取有关数字身份的信息(例如标题、许可证、资格、年龄等)。用户首先向访问管理合约请求，并提交自己的身份信息，其中包含了访问所需文件要求的属性信息；通过SAML2(Security Assertion Markup Language，安全声明标记语言)的架构，访问管理合约将请求转发到身份子链。之后，访问管理合约从身份子链获取的身份信息去属性子链中，获得该用户对应属性的证明；至此，访问管理合约已获得所有的属性验证信息。

最后，文件访问合约收到属性验证成功的消息，调用预言机(Oracle)检查访问管理合约先前步骤的总体有效性。如果检查成功，则文件访问合约会发出一个交易，确认验证完成。

步骤S633，文件访问合约收到授权消息，从属性子链中提取出对应属性策略的密钥给用户。

在发送交易之前，文件访问合约应该加密密钥pk防止其泄露给所有区块链参与者。文件访问合约使用用户的公钥加密pk，以获得EU pk(k)，文件访问合约通过具有作为输入数据EU pk(k)发起交易并提交至区块链，最终，该用户成为唯一可以使用自己的私钥解密EU pk(k)的人。在用户解密了pk之后，用户可以进一步使用pk对密文ei进行解密，从而获得明文文件di。

在本申请实施例中，用户请求访问文件时，先将自己需要访问的文件和自己的身份标识提交给区块链的访问管理合约，访问管理合约从哈希-属性映射表中找到该文件对应的属性策略，并根据从属性子链中找出该属性策略对应的具体属性，并通过身份子链访问来查询用户所拥有的身份属性(该步骤可能会涉及用户的隐私问题，身份子链可以由第三方或政府部门私有，通过外部接口来确认属性，而不直接公开身份子链。在用户的所有属性验证成功之后，文件访问合约收到授权消息，并验证授权操作过程的有效性，从属性子链中提取出对应属性策略的密钥给用户，用户即可解密文件进行访问。

在一些实施例中，由于使用了密钥分发的方式进行访问控制，因此密钥撤销需要由更新密钥来实现。全局密钥索引在属性子链中，因此也需要属性子链来实现密钥更新的操作，详细步骤如下：

属性子链的矿工在经过固定时间t之后，发起区块链交易(形成属性策略p到密钥pk的新映射)。在全局密钥索引表构建完成之后，通知区块链进行自动交易，由存储管理合约检索修改过的属性策略并对对应文件进行重新加密。此时，之前获得过密钥的所有用户都需要重新申请密钥来访问IPFS哈希对应的文件。

由于属性子链和区块链在属性策略更新阶段，无法对当前的用户身份进行验证，为了响应属性子链和区块链在更新属性策略时的访问请求，引入了从链。在设计中，从链与区块链具有相同的结构，平行于区块链，在区块链为保证前向撤销要求而进行的密钥更新的同时，从链可以通过访问管理合约访问属性子链，从而实现当前请求可以依据最新的属性策略进行验证，详细过程如下所示：

步骤S641，用户提出访问请求，如果区块链当前处于更新属性策略状态，区块链进行分叉产生平行从链；

步骤S642，用户以及随后发起请求的用户由从链的访问管理合约接收，并发起验证；

步骤S643，待区块链更新完成，将从链上的交易与区块链合并。

由于考虑到在一个从链的生命周期中主链可能有多次属性更新，因此合并交易时需要验证属性策略是否符合当前最新的属性策略。

以下表1和表2分别示出了区块链的交易记录元组和属性子链的交易记录元组，可以看出，区块链的交易记录元组包括哈希指针、文件名、用户标识、IPFS哈希值、属性处理、交易的时间戳，属性子链的交易记录元组包括哈希指针、参与方标识、属性策略以及包括的属性1、属性2等，还包括策略密钥和交易的时间戳：

表1

表2

在本申请实施例中，当属性子链的参与方申请改变某种属性策略时，在属性子链上发起交易。通过证书颁发机构认证参与方身份之后，参与方即可把新的属性策略发布至属性子链，同时生成新的密钥，即使用区块链的公钥加密新生成的密钥，并将加密后的密钥添加到区块链上，同时告知区块链属性策略修改。需要说明的是，为了防止其他参与方看到密钥，所以使用主链的公钥加密，只有主链可以获取真正的密钥。

区块链上的文件存储合约查看属性子链上的交易，找出对应修改(增加、更新、删除)的属性策略，并根据哈希属性映射表对被修改属性对应的文件使用新的密钥进行重新加密。值得注意的是，由于用户量巨大，无法实时每个用户的属性变化，因此属性子链可以在固定时间之后将会自动更新，更换密钥，来保证用户之前获取的密钥无效。

本申请实施例采用了多链结构，区块链包括属性子链和身份子链两个私有链，其中由属性子链存储属性策略与密钥之间的映射关系，由身份子链实现身份管理映射(由身份验证服务者提供)，实现了可拓展的属性分配，相比于传统的属性加密方法在动态更新方面更加友好。

本申请实施例通过侧链与主链的平行链结构，实现动态更新与撤销，即在主链为保证前向撤销要求而进行密钥更新的同时，从链可以通过访问管理合约访问属性子链，从而实现当前访问请求可以依据最新的属性策略进行验证。属性子链进行属性策略更新，并且在属性子链更新状态下，区块链分叉出从链来根据原属性策略备份进行交易，更新完成之后合并从链并进行验证，保证了在策略更新期间的正常交易，同时也可撤销在更新期间的密钥分发，实现了前向安全和后向安全。

相比于相关技术，本申请实施例至少具有以下技术优点：采用私有链来存储属性策略和身份策略，保证属性策略的安全性、隐私性。支持海量用户接入，并且使密钥访问可追溯、可监管；使用对称加密，而非CP-ABE加密算法，大大提高特别是大文件的读写效率。加密算法效率高，节约了计算开销和时间开销，大文件存储、多属性时，加解密时间可以满足实际应用；属性策略由文件共享平台方维护，身份策略由第三方服务者(政府部门、银行和医院等相关机构)提供。适用于用户数量多的场景(因为政府、银行和医院等机构具有庞大的用户群体)；同时，身份验证与属性策略分离，系统安全性更强；使用IPFS作为文件存储平台，区块链来记录IPFS文件哈希，节约区块链存储空间，并且提高了区块链吞吐量，在同样的块生成速度下，可以处理更多交易。

基于前述的实施例，本申请实施例再提供一种访问控制装置，所述装置包括所包括的各模块、以及各模块所包括的各单元，可以通过电子设备中的处理器来实现；当然也可通过具体的逻辑电路实现；在实施的过程中，处理器可以为中央处理器(CentralProcessing Unit，CPU)、微处理器(Micro Processing Unit，MPU)、数字信号处理器(Digital Signal Processor，DSP)或现场可编程门阵列(Field Programmable GateArray，FPGA)等。

图7为本申请实施例提供的一种访问控制装置的组成结构示意图，如图7所示，所述装置700包括第一接收模块710、第一确定模块720、第二确定模块730、属性验证模块740和授权模块750，其中：

所述第一接收模块710，用于通过所述区块链的访问管理合约接收第一用户对第一文件的访问请求；所述访问请求中包括所述第一用户的身份标识；

所述第一确定模块720，用于基于所述第一文件对应的第一属性策略，通过所述访问管理合约调用所述区块链的属性子链确定所述第一用户的属性信息；所述属性子链为用于对用户属性信息进行管理的私有链；

所述第二确定模块730，用于基于所述身份标识，通过所述访问管理合约调用所述区块链的身份子链确定所述第一用户的身份信息；所述身份子链为用于存储身份认证记录的私有链；

所述属性验证模块740，用于通过所述访问管理合约验证所述第一用户的属性信息和所述身份信息；

所述授权模块750，用于在所述第一用户通过验证的情况下，通过所述区块链的文件访问合约向所述第一用户授权。

在一些可能的实施例中，所述第一文件存储在分布式文件系统，所述装置700还包括获取模块、第三确定模块，其中：所述获取模块，用于所述访问管理合约获取所述第一文件在所述分布式文件系统的哈希值；所述第三确定模块，用于所述访问管理合约基于所述第一文件的哈希值，从预设的哈希属性映射表中，确定所述第一文件对应的第一属性策略；所述哈希属性映射表用于记录文件哈希值与属性策略之间对应关系。

在一些可能的实施例中，所述第二确定模块包括转发单元和第一确定单元，其中：所述转发单元，用于在所述属性子链中存在所述第一用户的属性信息的情况下，通过所述访问管理合约转发所述访问请求至所述区块链的身份子链；所述第一确定单元，用于基于所述身份标识，通过所述身份子链确定所述第一用户的身份信息。

在一些可能的实施例中，所述授权模块包括第二确定单元、第一加密单元和交易发布单元，其中：所述第二确定单元用于在所述第一用户通过验证的情况下，通过所述文件访问合约确定所述第一属性策略对应的第一密钥；所述第一密钥用于对所述第一文件对应的密文进行解密；所述第一加密单元，用于通过所述文件访问合约以所述第一用户的公钥加密所述第一密钥，得到第二密钥；所述交易发布单元，用于通过所述文件访问合约以所述第二密钥作为输入发起交易请求并将所述交易请求提交至所述属性子链，以实现对所述第一用户的授权；其中，所述第二密钥用于所述第一用户以自己的私钥进行解密得到所述第一密钥。

在一些可能的实施例中，所述装置还包括第一文件加密模块、文件发布模块和第一交易记录模块，其中：所述第一文件加密模块，用于所述响应于接收到存储第二文件的存储请求，通过所述区块链的存储管理合约对所述第二文件进行加密，得到所述第二文件对应的密文；所述存储管理合约用于将待存储文件与对应属性策略关联；所述文件发布模块，用于通过所述区块链的文件存储合约执行发布文件操作将所述密文发布在所述分布式文件系统上；其中，所述分布式文件系统用于存储所述密文并确定所述密文的哈希；所述第一交易记录模块，用于通过所述文件存储合约将所述发布文件操作作为一次交易记录在所述区块链中。

在一些可能的实施例中，所述第一文件加密模块包括查找单元、第三确定单元和第二加密单元，其中：所述查找单元，用于通过所述存储管理合约从所述属性子链中查找所述第二文件对应的第二属性策略；所述第三确定单元，用于通过所述存储管理合约确定所述第二属性策略对应的第三密钥；所述第二加密单元，用于通过所述存储管理合约以所述第三密钥对所述第二文件进行加密，得到所述第二文件对应的密文。

在一些可能的实施例中，所述第一文件加密模块还包括生成单元、关联单元和第一存储单元，其中：所述生成单元，用于在所述属性子链中未查找到所述第二文件对应的第二属性策略的情况下，通过所述存储管理合约生成新的第二属性策略；所述关联单元，用于通过所述存储管理合约将所述新的第二属性策略与所述第二文件关联，得到关联关系；所述第一存储单元，用于通过所述存储管理合约将所述关联关系存储在所述属性子链的哈希属性映射表中。

在一些可能的实施例中，所述装置700还包括策略更新模块、策略发布模块、密钥更新模块，其中：所述策略更新模块，用于在所述属性子链的参与方申请改变所述属性子链中的第三属性策略的情况下，通过所述访问管理合约验证所述参与方的身份；所述策略发布模块，用于在所述参与方的身份验证通过的情况下，通过所述存储管理合约将改变后的所述第三属性策略发布至所述属性子链；所述密钥更新模块，用于通过所述存储管理合约生成与改变后的所述第三属性策略对应的第四密钥并存储至所述属性子链。

在一些可能的实施例中，所述装置700还包括第二接收模块、生成模块、第二交易记录模块和合并模块，其中：所述第二接收模块，用于在所述属性子链和所述区块链处于更新属性策略状态的情况下，通过所述从链的访问管理合约接收第二用户的文件访问请求；所述生成模块，用于响应于所述文件访问请求，所述区块链生成具有相同结构的从链；所述第二交易记录模块，用于在所述第二用户通过验证的情况下，通过所述从链的文件访问合约将所述文件访问请求作为一个交易发布在所述从链上；所述合并模块，用于在所述区块链退出所述更新属性策略状态的情况下，将所述从链上的交易合并至所述区块链。

在一些可能的实施例中，所述装置700还包括第四确定模块、第五确定模块和第二文件加密模块，其中：所述第四确定模块，用于通过所述文件存储合约查看所述属性子链上的交易，确定至少一个变化的属性策略；所述第五确定模块，用于通过所述文件存储合约从所述哈希属性映射表中确定所述至少一个变化的属性策略对应的文件；所述第二文件加密模块，用于通过所述存储管理合约以所述第四密钥对所述至少一个变化的属性策略对应的文件进行重新加密。

这里需要指出的是：以上装置实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本申请装置实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。

需要说明的是，本申请实施例中，如果以软件功能模块的形式实现上述访问控制方法，并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得电子设备(可以是具有摄像头的智能手机、平板电脑等)执行本申请各个实施例所述方法的全部或部分。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read Only Memory，ROM)、磁碟或者光盘等各种可以存储程序代码的介质。这样，本申请实施例不限制于任何特定的硬件和软件结合。

对应地，本申请实施例提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述实施例中任一所述访问控制方法中的步骤。对应地，本申请实施例中，还提供了一种芯片，所述芯片包括可编程逻辑电路和/或程序指令，当所述芯片运行时，用于实现上述实施例中任一所述访问控制方法中的步骤。对应地，本申请实施例中，还提供了一种计算机程序产品，当该计算机程序产品被电子设备的处理器执行时，其用于实现上述实施例中任一所述访问控制方法中的步骤。

基于同一技术构思，本申请实施例提供一种电子设备，用于实施上述方法实施例记载的访问控制方法。图8为本申请实施例提供的一种电子设备的硬件实体示意图，如图8所示，所述电子设备800包括存储器810和处理器820，所述存储器810存储有可在处理器820上运行的计算机程序，所述处理器820执行所述程序时实现本申请实施例任一所述访问控制方法中的步骤。

存储器810配置为存储由处理器820可执行的指令和应用，还可以缓存待处理器820以及电子设备中各模块待处理或已经处理的数据(例如，图像数据、音频数据、语音通信数据和视频通信数据)，可以通过闪存(FLASH)或随机访问存储器(Random Access Memory，RAM)实现。

处理器820执行程序时实现上述任一项的访问控制方法的步骤。处理器820通常控制电子设备800的总体操作。

上述处理器可以为特定用途集成电路(Application Specific IntegratedCircuit，ASIC)、数字信号处理器(Digital Signal Processor，DSP)、数字信号处理装置(Digital Signal Processing Device，DSPD)、可编程逻辑装置(Programmable LogicDevice，PLD)、现场可编程门阵列(Field Programmable Gate Array，FPGA)、中央处理器(Central Processing Unit，CPU)、控制器、微控制器、微处理器中的至少一种。可以理解地，实现上述处理器功能的电子器件还可以为其它，本申请实施例不作具体限定。

上述计算机存储介质/存储器可以是只读存储器(Read Only Memory，ROM)、可编程只读存储器(Programmable Read-Only Memory，PROM)、可擦除可编程只读存储器(Erasable Programmable Read-Only Memory，EPROM)、电可擦除可编程只读存储器(Electrically Erasable Programmable Read-Only Memory，EEPROM)、磁性随机存取存储器(Ferromagnetic Random Access Memory，FRAM)、快闪存储器(Flash Memory)、磁表面存储器、光盘、或只读光盘(Compact Disc Read-Only Memory，CD-ROM)等存储器；也可以是包括上述存储器之一或任意组合的各种电子设备，如移动电话、计算机、平板设备、个人数字助理等。

这里需要指出的是：以上存储介质和设备实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本申请存储介质和设备实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。

应理解，说明书通篇中提到的“一个实施例”或“一实施例”意味着与实施例有关的特定特征、结构或特性包括在本申请的至少一个实施例中。因此，在整个说明书各处出现的“在一个实施例中”或“在一实施例中”未必一定指相同的实施例。此外，这些特定的特征、结构或特性可以任意适合的方式结合在一个或多个实施例中。应理解，在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。

上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以是、或也可以不是物理单元；既可以位于一个地方，也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部单元来实现本申请实施例方案的目的。

另外，在本申请各实施例中的各功能单元可以全部集成在一个处理单元中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

或者，本申请上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得设备自动测试线执行本申请各个实施例所述方法的全部或部分。而前述的存储介质包括：移动存储设备、ROM、磁碟或者光盘等各种可以存储程序代码的介质。

本申请所提供的几个方法实施例中所揭露的方法，在不冲突的情况下可以任意组合，得到新的方法实施例。

本申请所提供的几个方法或设备实施例中所揭露的特征，在不冲突的情况下可以任意组合，得到新的方法实施例或设备实施例。

以上所述，仅为本申请的实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (13)

1.一种访问控制方法，其特征在于，应用于区块链，所述方法包括：

通过所述区块链的访问管理合约接收第一用户对第一文件的访问请求；所述访问请求中包括所述第一用户的身份标识；

基于所述第一文件对应的第一属性策略，通过所述访问管理合约调用所述区块链的属性子链确定所述第一用户的属性信息；所述属性子链为用于对用户属性信息进行管理的私有链；

基于所述身份标识，通过所述访问管理合约调用所述区块链的身份子链确定所述第一用户的身份信息；所述身份子链为用于存储身份认证记录的私有链；

通过所述访问管理合约验证所述第一用户的属性信息和所述身份信息；

在所述第一用户通过验证的情况下，通过所述区块链的文件访问合约向所述第一用户授权。

2.如权利要求1所述的方法，其特征在于，所述第一文件存储在分布式文件系统，所述方法还包括：

所述访问管理合约获取所述第一文件在所述分布式文件系统的哈希值；

所述访问管理合约基于所述第一文件的哈希值，从预设的哈希属性映射表中，确定所述第一文件对应的第一属性策略；所述哈希属性映射表用于记录文件哈希值与属性策略之间对应关系。

3.如权利要求1所述的方法，其特征在于，所述基于所述身份标识，通过所述访问管理合约调用所述区块链的身份子链确定所述第一用户的身份信息，包括：

在所述属性子链中存在所述第一用户的属性信息的情况下，通过所述访问管理合约转发所述访问请求至所述区块链的身份子链；

基于所述身份标识，通过所述身份子链确定所述第一用户的身份信息。

4.如权利要求2所述的方法，其特征在于，所述在所述第一用户通过验证的情况下，通过所述区块链的文件访问合约向所述第一用户授权，包括：

在所述第一用户通过验证的情况下，通过所述文件访问合约确定所述第一属性策略对应的第一密钥；所述第一密钥用于对所述第一文件对应的密文进行解密；

通过所述文件访问合约以所述第一用户的公钥加密所述第一密钥，得到第二密钥；

通过所述文件访问合约以所述第二密钥作为输入发起交易请求并将所述交易请求提交至所述属性子链，以实现对所述第一用户的授权；其中，所述第二密钥用于所述第一用户以自己的私钥进行解密得到所述第一密钥。

5.如权利要求1至4任一项所述的方法，其特征在于，所述方法还包括：

响应于接收到存储第二文件的存储请求，通过所述区块链的存储管理合约对所述第二文件进行加密，得到所述第二文件对应的密文；所述存储管理合约用于将待存储文件与对应属性策略关联；

通过所述区块链的文件存储合约执行发布文件操作将所述密文发布在所述分布式文件系统上；其中，所述分布式文件系统用于存储所述密文并确定所述密文的哈希；

通过所述文件存储合约将所述发布文件操作作为一次交易记录在所述区块链中。

6.如权利要求5所述的方法，其特征在于，所述通过所述区块链的存储管理合约对所述第二文件进行加密，得到所述第二文件对应的密文，包括：

通过所述存储管理合约从所述属性子链中查找所述第二文件对应的第二属性策略；

通过所述存储管理合约确定所述第二属性策略对应的第三密钥；

通过所述存储管理合约以所述第三密钥对所述第二文件进行加密，得到所述第二文件对应的密文。

7.如权利要求6所述的方法，其特征在于，所述方法还包括：

在所述属性子链中未查找到所述第二文件对应的第二属性策略的情况下，通过所述存储管理合约生成新的第二属性策略；

通过所述存储管理合约将所述新的第二属性策略与所述第二文件关联，得到关联关系；

通过所述存储管理合约将所述关联关系存储在所述属性子链的哈希属性映射表中。

8.如权利要求1至4任一项所述的方法，其特征在于，所述方法还包括：

在所述属性子链的参与方申请改变所述属性子链中的第三属性策略的情况下，通过所述访问管理合约验证所述参与方的身份；

在所述参与方的身份验证通过的情况下，通过所述存储管理合约将改变后的所述第三属性策略发布至所述属性子链；

通过所述存储管理合约生成与改变后的所述第三属性策略对应的第四密钥并存储至所述属性子链。

9.如权利要求8所述的方法，其特征在于，所述方法还包括：

在所述属性子链和所述区块链处于更新属性策略状态的情况下，通过所述从链的访问管理合约接收第二用户的文件访问请求；

响应于所述文件访问请求，所述区块链生成具有相同结构的从链；

在所述第二用户通过验证的情况下，通过所述从链的文件访问合约将所述文件访问请求作为一个交易发布在所述从链上；

在所述区块链退出所述更新属性策略状态的情况下，将所述从链上的交易合并至所述区块链。

10.如权利要求8所述的方法，其特征在于，所述方法还包括：

通过所述文件存储合约查看所述属性子链上的交易，确定至少一个变化的属性策略；

通过所述文件存储合约从所述哈希属性映射表中确定所述至少一个变化的属性策略对应的文件；

通过所述存储管理合约以所述第四密钥对所述至少一个变化的属性策略对应的文件进行重新加密。

11.一种访问控制装置，其特征在于，所述装置包括：

第一接收模块，用于通过所述区块链的访问管理合约接收第一用户对第一文件的访问请求；所述访问请求中包括所述第一用户的身份标识；

第一确定模块，用于基于所述第一文件对应的第一属性策略，通过所述访问管理合约调用所述区块链的属性子链确定所述第一用户的属性信息；所述属性子链为用于对用户属性信息进行管理的私有链；

第二确定模块，用于基于所述身份标识，通过所述访问管理合约调用所述区块链的身份子链确定所述第一用户的身份信息；所述身份子链为用于存储身份认证记录的私有链；

属性验证模块，用于通过所述访问管理合约验证所述第一用户的属性信息和所述身份信息；

授权模块，用于在所述第一用户通过验证的情况下，通过所述区块链的文件访问合约向所述第一用户授权。

12.一种电子设备，包括存储器和处理器，所述存储器存储有可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现权利要求1至10任一项所述方法中的步骤。

13.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该计算机程序被处理器执行时实现权利要求1至10中任一项所述方法中的步骤。

Images