基于区块链的物联网访问控制框架

史锦山，李 茹*，松婷婷

（1. 内蒙古大学计算机学院，呼和浩特010021；2. 内蒙古自治区无线网络与移动计算重点实验室（内蒙古大学），呼和浩特010021）

（∗通信作者电子邮箱csliru@imu.edu.cn）

0 引言

物联网中产生了海量的数据，其中含有大量的个人隐私，这些隐私信息一旦泄漏会给用户带来巨大的损失。作为数据保护的基石性技术之一，访问控制可保障数据仅能被拥有相应权限的用户访问［1］。因此，物联网下的访问控制机制也就成为了物联网安全和隐私保护的重要研究内容之一。

区块链是一种去中心化的分布式技术，从技术上解决了基于信任的中心化模型带来的安全问题，因此研究者将区块链与访问控制结合来作为物联网数据保护的关键技术。

目前将区块链应用到访问控制中的研究可以分为两类:一类是区块链技术与现有的物联网访问控制模型相结合［2-10］，另一类是在区块链平台上重新设计访问控制模型［11-23］。

与现有物联网访问控制模型相结合的研究主要是为了解决现有访问控制模型的集中式授权决策实体带来的多机构间安全信任问题［2-6］和单点故障问题［7-10］。区块链在互不信任的节点间构建了一个可信的环境，研究者目前已经解决了基于角色的访问控制（Role-Based Access Control，RBAC）［2］、基于属性的访问控制（Attributes Based Access Control，ABAC）［3-5］、基于权能的访问控制（Capability-Based Access Control，CapBAC）［6］中因为信任而带来的一些问题。另一些研究者则利用区块链去中心的特征解决了CapBAC［7-8］、CP-ABE（Ciphertext Policy Attribute Based Encryption）［9］、SmartOrBAC（Smart Organization-Based Access Control）［10］中 的 单 点 故 障问题。

在区块链平台上重新设计访问控制模型，这类研究充分利用区块链的去中心化、不可篡改、可溯源和智能合约的特性，将区块链作为可信实体构建访问控制模型［11-23］。研究者们首先初步探索了在区块链上设计新的框架的可行性，如文献［11-15］在区块链上提出了各自重新设计的访问控制模型。接着，研究者们提出了更详细的访问过程而不仅限于框架:Zhang 等［16］提出了一种静态的访问控制模型；Ramachandran等［17］提出了一种科学数据来源的管理方法；Ali等［18］提出了一种物联网下的访问控制模型，并对事件和查询基础权限委托提出了要求。更进一步，研究者们解决了物联网环境中的关键问题:Dorri 等［19］提出一种方法使用token 来缓解区块链存在时间、计算和存储开销巨大的问题；Lin 等［20］解决了细粒度访问；Novo 等［21］提出的模型具有可伸缩性；Alphand 等［22］的模型具有灵活性；Ma等［23］提出的模型可跨域访问。

尽管进行了许多将区块链与访问控制相结合的研究，但是目前这些访问控制模型并不成熟，没有统一考虑物联网海量性、动态性和设备轻量级的特征。事实上这三个特征在物联网中是内在联系并同时存在的，物联网中存在海量的用户，用户会随时移动，每个用户通常都拥有多个物联网终端设备，且这些设备多数是轻量级的。因此本文将这三个特征放在一起讨论，其中:海量性为访问控制带来了更为复杂的管理难度，需要管理海量的用户、终端设备和多样的设备种类、数据类型以及更复杂的应用；动态性代表着访问控制必须支持节点的移动和动态接入；设备轻量级则代表着设备并不能为访问控制提供太多的计算和存储能力。

因此，本文提出了一种基于区块链的物联网访问控制（Blockchain-based IoT Access Control，BBIAC）框架，该框架包括BBIAC 模型和工作流程。为了满足海量性的要求，BBIAC模型参考了ABAC 中关于属性的概念，将主体和客体的属性作为基本的决策要素，通过构建｛属性，权限｝关联关系简化了大规模用户的管理难度。接着，区块链自身分布式结构和身份认证方式为BBIAC 提供了节点的移动性和节点的动态接入的功能，同时提供权限传递功能满足了物联网中权限的动态转移。最后，由区块链所提供的安全性和多机构间的信任，使BBIAC 可以将需要大规模计算和存储的部分部署在区块链中，因此本模型支持轻量级的物联网设备。

本文的工作主要有:1）提出了一种物联网下的访问控制模型，结合了ABAC 中属性的概念和CapBAC 中令牌的概念，以区块链为主体解决了物联网三种环境特征带来的挑战，并给出模型对应的工作流程；2）利用着色Perti 网（Colored Petri Net，CPN）对BBIAC模型进行形式化的安全性证明；3）通过实验分析验证了BBIAC 对海量性、动态性和设备轻量级的支持，实验结果表明BBIAC 适用于物联网环境，并通过实验测试了不同共识算法对模型性能的影响。

1 访问控制模型

1.1 模型设计

物联网环境具有海量性、动态性、设备轻量级的特征，BBIAC 作为物联网下的访问控制模型，需要适应这些特征。因此BBIAC 模型在设计时同时兼顾了物联网海量性、动态性和设备轻量级的特征。

BBIAC 模型的设计思想如下:1）针对物联网的海量性，BBIAC 模型吸收了ABAC 中属性的概念，将属性作为基本的决策要素，并在ABAC 的基础上进行了扩展；2）由区块链数字签名实现的身份认证和P2P（Peer-to-Peer）网络结构满足了物联网的动态性，同时提供了权限的动态转移；3）区块链所提供的多机构间的信任，使BBIAC 可以将需要大规模计算和存储的部分部署在安全可信的区块链中，因此本模型支持轻量级的物联网设备；4）为了克服区块链响应时间过慢的缺点，将权限映射为token，然后通过token 提前申请、多次使用的访问方法，减小区块链对访问控制性能的影响。

综合以上的考虑，访问控制模型设计如图1 所示，由以下三部分组成:

1）实体。包括主体（Subject，S）、客体（Object，O）、权限（Permission，P）、资源拥有者（Resource Owner，R）、Token 和事件（Event，E）。

2）实体间的关系。包括主体和Token 的关系（ST）、Token和权限（TP）、权限和客体（PO）、客体和资源拥有者（OR），以及事件与其他主体之间的关系。由于事件的不同，各种事件与主体之间的关系也各不相同。

3）属性。包括实体属性和环境属性两类，实体属性会出现继承的现象，后文详细介绍。

图1 基于区块链的物联网访问控制模型Fig. 1 Blockchain-based IoT access control model

1.2 实体

实体是访问控制模型中实际参与访问控制的集合。模型通过六元组（S，O，P，R，Token，E）表示物联网中的访问控制所涉及到的实体。

主体是主动发起访问请求的实体集合，通过S（t）=｛s1，s2，…，sn｝表示t时刻物联网中的某个主动发起访问请求的主体si的集合。

客体是物联网中可被访问的实体集合，这里的客体可以是数据、文件、程序、物联网设备等虚拟和现实中所有可被访问的资源，通过O（t）=｛o1，o2，…，on｝表示t 时刻物联网中可被访问的资源oi的集合。

权限是主体S 对客体O 操作的范围和程度的实体集合，通过P=｛p1，p2，…，pn｝表示物联网中的权限，包括数据的读、写、新建、删除和对物联网设备的操作等。

资源拥有者R 是客体O 拥有者的实体集合，客体的访问策略都是由其资源拥有者制定，通过R（t）=｛r1，r2，…，rn｝表示t时刻物联网中的资源拥有者ri的集合。

Token是访问控制策略对主体授予的权限的实体集合，通过Tokenij（p，tstart，tend）=｛tokenij（p，tstart，tend）|i∈S（tstart），j∈O（tstart），p∈P｝表示，tokenij（p，tstart，tend）表示tstart到tend期间主体si拥有对客体oj的操作权限p。

事件是访问控制模型中对token 操作的一组智能合约的集合，通过E=｛e1，e2，…，en｝表示，事件包括请求访问事件、token 生成事件、token 传递事件和token 使用事件等。之所以将操作token 的数个合约抽象出来形成事件实体，是因为对token的操作是访问控制模型的核心。

1.3 实体间的关系

主体S 和Token 的关系通过ST⊆S×Token 表示，主体与Token 是一对多的关系，即每个主体可以同时拥有多个token，每个token只能对应一个主体。

Token 和权限P 的关系通过TP⊆Token×P 表示，Token 和权限是多对多的关系，一个token 可以对应一个客体的多个权限，同时一个客体的权限可以生成多个token 分发给多个主体。

权限P 和客体O 的关系通过PO⊆P×O 表示，权限和客体是多对一的关系，一个客体可能会映射出多个可被访问的权限。例如对于网络摄像头来说其权限有开、关、转动方向等操作权限。

客体O 和资源拥有者R 的关系通过OR⊆O×R 表示，客体和资源拥有者是多对一的关系，即一个客体对应一个资源拥有者，一个资源拥有者可能拥有多个客体。

事件E 与其他实体间的关系较为复杂，且不同事件与其他实体的关系也是不同的。

请求访问事件与主体S、客体O 和权限P 有直接关系，通过AccessRequest（s，o，p）表示，其中访问请求事件与主体S 和客体O 都是一对一的关系，与权限P 是一对多的关系，因为主体可以同时请求客体的多项权限。

token 生成事件与客体O、权限P 和Token 有直接关系，通过CreateToken（o，p）-＞token（p，tstart，tend）表示。token 生成事件与Token 是一对一的关系，每个token 生成事件会创建一个新的token。在生成token 时需要确定token 所对应的客体和权限，一个token 对应一个客体，但是可以对应同一客体下的多个权限，这些权限必须是客体自身的权限的子集。

token 传递事件与主体和Token 有直接关系，通过TransferToken（sfrom，sto，token（p，tstart，tend））-＞token（p，tstart，tend）表示。每个token 传递事件和主体是1∶2 的关系，即一个主体发起传递，一个主体接收token。token 传递事件和Token 是一对一的关系，每个token传递事件只能传递一个token。

token 使用事件同样仅与主体和Token 有关联，通过UseToken（s，tokensj（p，tstart，tend））-＞pj表示，不同的是token使用事件与主体是一对一的关系，和Token同样也是一对一的关系。

1.4 属性

属性是对物联网中的事物以访问控制为视角的抽象，提取出的与访问控制相关的性质。模型中的属性分为实体属性和环境属性两类。

这里首先需要对本文中属性间的继承和约束作出定义，然后逐一介绍各项属性。

定义1 属性继承。实体间的属性存在继承的现象，即继承者实体的属性分为两部分:一部分属性继承自被继承者实体；一部分是自己特有的属性，自己特有的属性不会和继承属性冲突。

定义2 属性间的约束。继承者实体在继承了被继承者实体的属性后，会受到被继承者实体属性的约束，或者说它的行为必须满足它所继承的属性。

例如对于固定安装的网络摄像头来说是不存在移动和存储功能的，因此它的权限也不包括移动和写入，而是只有读取、开关机、转动方向等权限。因此，根据客体的不同，其分化出的权限的子集也是不同的。属性与约束的关系如图2所示。

主体的属性是指主体自身固有的、与环境变化无关的、与访问控制有关的属性，如年龄、性别、职业、职务等。使用SA表示主体属性的集合，对于某个主体si的属性集合表示为si.a=｛aj|aj∈si.SA｝，其中si∈S（t）。

图2 实体属性与约束范围的关系示意图Fig. 2 Schematic diagram of relationship between entity attributes and constraint range

客体的属性是指客体自身固有的、与环境变化无关的、与访问控制有关的属性。在物联网中客体的属性的多种多样的。例如对于公共会议室的门禁系统，同一时间段内应该只允许一个使用者，因此会议室在同一时间段只能发出一个token；而像手机中三轴加速传感器，可以同时给多个App传递用户的步数，因此同一时间段可以发出多个token。使用OA表示客体属性的集合，对于某个客体oi的属性表示为:oi. a=｛ai|ai∈oi.OA｝。

权限的属性包括自身固有属性和继承自其对应客体的属性，使用PA表示权限属性的集合，对于某个客体oi的权限pj的属性表示为:oi.pj.a=｛ak|ak∈pj.PA｝，同时oi.a⊆oi. pj.a。权限自身固有的属性包括权限是永久赋予、按时间赋予还是按次数赋予等，权限继承自其对应客体的属性受客体属性的约束。

Token 的属性包括自身固有属性和从对应权限继承的属性两部分。自身固有属性包括token 拥有者、有效时间、是否可传递等。从对应权限继承的属性受权限属性的约束，同时从对应权限继承的属性会影响token 的自身固有属性。以公共会议室为例，主体sA得到的token 是某日上午8:00—12:00的使用权限，如果sA在10:00时会议结束，则可以将token传递给需要的sB，前提是sB符合token的使用要求。使用TA表示权限属性的集合，对于某个tokeni的属性表示为:tokeni.a=｛aj|aj∈tokeni.PA｝，其中oi.pj.a⊆tokeni.a。

环境属性是指除实体属性外对物联网访问控制有影响的环境因素。通过EA 表示环境属性的集合。对物联网来说常见的环境属性有时间、位置、光照、温度、声音等。

资源拥有者和事件实体的属性对访问控制的影响微乎其微，这里并没有将其单独列出。

2 模型工作流程

上文描述了模型的形式化定义，这里将详细介绍模型的工作流程。访问控制流程分为如下4 个部分:用户注册、请求访问、访问资源和权限传递（permission delegation）。

2.1 用户注册

首先是用户注册流程，系统中的每个主体和客体都需要在BBIAC 中注册。主体的注册仅需要用户在部署访问控制的区块链中注册账户即可，这里就不再赘述了。而客体的注册是由资源拥有者主动执行的，注册的内容包括为客体取得一个ID 以及设置客体的属性和访问控制策略等。具体流程如算法1所示。

算法1 的第1）～3）中，资源拥有者r 将自己所拥有的资源作为访问客体发布在BBIAC 中。第4）步检测发布的内容是否合法，主要检测访问控制策略是否与客体属性有冲突，例如对于温度传感器来说，如果资源拥有者在其属性设置时只为其设置了读属性，但是在其访问控制策略中却有读和写两个权限，这就属于策略和客体属性冲突，需要重新上传正确的访问策略。

考虑到某些情况需要更改属性和访问策略，因此提供了更新客体属性和访问策略的方法。属性的更新和访问策略的更新都会触发相应的事件，因此都会被区块链记录并永久保存。

2.2 请求访问

访问请求的完整表述是主体s 请求客体o 的访问权限。因此主体需要发送一个四元组的消息（s，r，o，｛o. p1，o. p2，…，o.pi｝）给区块链，分别是消息的发起者请求主体s、客体o、o的拥有者r 和所请求的权限组｛o.p1，o.p2，…，o.pi｝，其中所请求的权限可以是一个也可以是多个。具体流程如算法2所示。

算法2 中，主体s 发送访问请求消息（s，r，o，｛o.p1，o.p2，…，o.pi｝）给BBIAC，BBIAC 收到消息后首先验证消息是否正确，验证通过后BBIAC 根据访问请求消息获得的参数查找主体和客体的属性s.a 和o.a，同时调用GetEnvironmentAttr（）获取当前的环境属性进入决策阶段，Decision（）利用获取到的o. a，s.a，e.a，｛o.p1，o.p2，…，o.pi｝作出决策，判断是否授予权限。如果决定授予权限，则BBIAC 生成一个对应的tokenso，并将该tokenso传递给主体。

其中决策过程Decision（）如算法3 所示。BBIAC 根据主体属性s.a、客体属性o.a、环境属性e.a、请求的权限｛o.p1，o.p2，…，o.pi｝来决策是否授予主体访问权限。

2.3 访问资源

主体在得到tokenso后，可以凭借tokenso访问该tokenso所对应的客体资源。访问资源需要主体发送一个五元组的消息（s，r，o，tokenso，｛o.p1，o.p2，…，o.pi｝）给区块链，分别是消息的发起者请求主体s，被访问者也就是客体o 的拥有者r，客体o，所使用的tokenso和将要使用的权限｛o. p1，o. p2，…，o. pi｝。流程如算法4所示。

算法4 中，主体s 发送访问资源的五元组消息（s，r，o，tokenso，｛o.p1，o.p2，…，o.pi｝）给BBIAC，BBIAC 收到消息后首先验证消息是否正确，验证通过则判断｛o.p1，o.p2，…，o.pi｝⊆｛o.px，…，o.py｝是否成立，是则主体拥有｛o.p1，o.p2，…，o.pi｝权限访问客体。

2.4 权限传递

权限传递使物联网中的权限管理更加灵活。主体s 发送一个三元组的消息（sfrom，sto，tokenso）给BBIAC，分别是消息的发起者主体同时也是tokenso的拥有者sfrom，传递的目的地主体sto和所传递的tokenso。具体流程如算法5所示。

算法5 中，首先发起传递tokenso的主体sfrom，发送tokenso传递的三元组消息（sfrom，sto，tokenso）给BBIAC，合法性验证通过后进行权限约束性检测，即主体sto是否有资格使用tokenso，如果确认有资格使用则将tokenso由主体传sfrom递给主体sto。

3 安全性分析

3.1 安全问题描述

BBIAC模型的安全性评价指标主要从以下三个方面展开分析:

首先是简单安全问题，是指访问控制模型在任意一个状态下，都不存在未授权用户对指定资源访问的情况，也就是说不存在权限的泄露，如果存在则模型是不安全的［24］。

第二个问题是简单可用性问题，指访问控制模型在可达的系统状态中，已授权用户可以访问指定资源，如果是则该模型是安全的。简单可用性问题保证了模型的正确性，即已授权用户可以使用该权限访问指定资源［24］。

第三个问题是约束继承问题，是指模型中的约束条件是向下继承的，权限授予时不能越过约束条件，如果越过约束条件则模型是不安全的。

其中:前两项来自于文献［24］，是所有访问控制模型必须要满足的条件；第三项是针对BBIAC模型提出的安全条件。

3.2 Petri网建模

为了分析模型是否满足上述三个安全性问题，需要通过数学模型分析BBIAC 模型设计和工作流程。本文选择了具有严格数学定义的数学建模工具Petri网进行建模。

CPN 通过九元组（Places，T，A，∑，V，C，G，E，I）模型来表述。这里对BBIAC 建立了一个三层结构的CPN 模型，图形化表示如图3～10 所示。接下来将介绍CPN 九元组的组成。需要注意的是，token 同时也是Petri 网中的一个原语，为了防止本文中概念的冲突，本文中所有Petri 网中的token 都用Petri_token表示。

3.2.1 颜色集和变量集

首先介绍的是颜色集∑，根据BBIAC 建模的需要定义了9个颜色集，具体定义及含义如表1所示。

变量集V 中的变量用在弧表达式中，变量所对应的颜色集如表2所示。

表1 BBIAC中的Petri网颜色集定义Tab. 1 Petri net color set definition in BBIAC

表2 变量集Tab. 2 Variable set

3.2.2 位置集、变迁集、弧集以及相关函数

CPN 图中椭圆形为位置集Places，也称为库所集。库所右上角是初始化函数I，右下角是着色函数C。

CPN 图中矩形为变迁集T，其中矩形线条是双线的是替代变迁，表示这个变迁下还有一层模型。变迁的左上方是该变迁的防卫函数G。

CPN 图中库所与变迁直接由弧所连接，所有的弧组成弧集A。每个弧上都有弧表达式函数E。

顶层模型如图3 所示具有8 个库所，5 个替代变迁，由28条弧将其连接起来。

其中替代变迁RegisteredSubject 的子页模型如图4 所示，其中RepeatabilityTest 变迁点火用来检测主体是否已注册，如果没有则可以点火RegisteredSubject 来在系统中注册新的主体。

替代变迁RegisteredObject 的子页模型如图5 所示，首先通过RepeatabilityTest 变迁点火用来检测客体是否合法，然后通过CollisionDetetion 变迁检测客体属性和策略是否冲突，如果前两个变迁点火成功，则通过RegisteredResources 变迁注册新的客体。

替代变迁RequestAccess 的子页模型如图6 所示，其中GetObject 和GetSubject 变迁点火获取到当前系统中的客体和主体。RequestAccess 变迁点火表示主体请求客体的某个请求。Get_s_att 替代变迁点火用来获取主体的属性，其中Get_s_attl 变迁的点火是准备主体的属性集。Get_op_att 替代变迁用来获取被请求的客体权限的属性，其中Get_p_attl变迁的点火是准备客体权限的属性集。Decision 变迁点火判断主体是否有权访问客体。AuthorityGrantingDecision 变迁点火做出决策是否将客体的权限授予主体，如果授予则生成对应的token。

替代变迁AccessResources 的子页模型如图7 所示，GetToken 变迁点火表示主体查找自己已经得到的token，AccessResources变迁点火表示使用token访问某资源。

替代变迁TransferAccess 的子页模型如图8 所示，其中Control 变迁是用来控制TransferAccess 变迁的点火时间，TransferAccess 变迁点火表示系统收到权限传递消息。Test变迁模拟系统检测权限传递的合法性。RemoveToken 变迁点火表示删除旧的token，AddNewToken 变迁点火表示添加新的token，以此模拟token的传递。

本模型中第三层仅有两个子页，且都在替代变迁RequestAccess 的子页中。Get_s_att 替代变迁的子页模型如图9 所示，GetSData 变迁点火获取系统当前的主体属性集和需要搜索的主体，Result 变迁点火实现搜索并输出结果。Get_op_att 替代变迁的子页模型如图10 所示，GetOData 变迁点火获取系统当前的客体属性集和需要搜索的客体，Result变迁点火实现搜索并输出结果。这里作了一定程度的抽象，在不流失BBIAC 关键要素的前提下，忽略了一些数据处理的细节。

图3 BBIAC顶层模型Fig. 3 BBIAC top-level model

图4 RegisteredSubject子页模型Fig. 4 RegisteredSubject subpage model

图5 RegisteredObject子页模型Fig. 5 RegisteredObject subpage model

图6 RequestAccess子页模型Fig. 6 RequestAccess subpage model

图7 AccessResources子页模型Fig. 7 AccessResources subpage model

图8 TransferAccess子页模型Fig. 8 TransferAccess subpage model

图9 Get_s_att子页模型Fig. 9 Get_s_att subpage model

图10 Get_op_att子页模型Fig. 10 Get_op_att subpage model

3.3 基于CPN的安全问题检测

3.3.1 简单安全问题

定义3 简单安全问题。对于任意的变迁点火序列R（M），如果存在M［AccessResources ＞，必然在其前面存在M［AuthorityGrantingDecision ＞M′，否则该模型就是不安全的。

证明

对 于 BBIAC 的 CPN 模 型 ， 如 果 想 要M［AccessResources ＞，即AccessResources 为可点火（enabled）状态，需要AccessResources变迁的三个输入库所log、tokens和subject 都非空。这里非空的意思是库所中拥有petri_token，因此petri_token的值为空并不等于库所是非空的。

其中log 库所都由初始化函数赋予了初始值，在M0 时是非空的，同时log 库所在作为日志在设计时并没有删除的功能，所以log库所是非空的。

而tokens 库所在M0 时的初始值是［］，在M0 时是一张空表。只 有 点 火 且E（AuthorityGrantingDecision，tokens）＜if authority＞= policy then 1`（（subject，object，authority）::tokenlist）else 1`tokenlist＞= 1`（（subject，object，authority）::tokenlist）才会在tokens 库所中填入新的值。虽然模型中的token 仅仅只在传递时会由RemoveToken 变迁实现token 删除操作，但会马上由AddNewToken 变迁将新的token 添加到tokens 库所中。同时系统中设置的传递token 的比例较小，不会出现所有token都被删除的情况。因此tokens是非空的。

subject 库所的值由GetToken 变迁点火生成，而GetToken变迁的输入库所是tokens，如果输入值为［］则输出弧的弧表达式函数会将输出变为空，因此只有当E（tokens，GetToken）＜token::tokenlist＞≠1`［］时，subject 库所才可能会非空。而想要E（tokens，GetToken）＜token::tokenlist＞≠1`［］就必须满足tokens≠1`［］。而 想 要tokens≠1`［］就 必 须 满 足 之 前 存 在E（AuthorityGrantingDecision，tokens）＜if authority＞= policy then 1`（（subject，object，authority）::tokenlist）else 1`tokenlist＞=1`（（subject，object，authority）::tokenlist）。

综 上 所 述 ， BBIAC 模 型 中 只 有 存 在M ［AuthorityGrantingDecision ＞ M′ 且 出 现E（AuthorityGrantingDecision，tokens）＜if authority＞= policy then 1`（（subject，object，authority）::tokenlist）else 1`tokenlist＞=1`（（subject，object，authority）::tokenlist）才 会 出 现M［AccessResources＞，因此模型在简单安全问题1方面是安全的。 证毕。3.3.2 简单可用性问题

简单可用性问题在CPN 环节中可以转化为可达性问题，即模型可以从标识Mi经过某些点火序列后到达标识Mj，其中j＞i。因此简单可用性问题的定义如下:

定义4 简单可用性问题。对于任意标识序列R（M），当M ［AuthorityGrantingDecision ＞ M′ 且 出 现E（AuthorityGrantingDecision，tokens）＜if authority＞= policy then 1`（（subject，object，authority）::tokenlist）else 1`tokenlist＞=1`（（subject，object，authority）::tokenlist），必然存在变迁点火序列［ti，ti+1，…，ti+n］使M［AccessResources＞出现。否则该模型就是不安全的。

证明

这个问题通过模型的状态空间图可以很容易地证明，但是由于状态空间图太大这里不容易说明问题，所以这里使用标识序列图来证明。一次典型的点火序列如表3 所示。其中:第1～3步的作用是在RegisteredObject 子页中注册客体；第4～5 步变迁点火是在RegisteredSubject 子页中注册主体；第6～14 步变迁点火是在RequestAccess 子页中实现的用户请求访问权限的过程；第15～19 步变迁点火是在TransferAccess 子页中传递token；第20～21 步变迁点火是在AccessResources 子页中使用token访问资源。

由于第15～19 步变迁点火序列是为了传递token，所以这个序列段可以重复执行，也可以不执行，根据使用场景变化而改变，但是并不影响证明。

在上述的标识序列中，M13 标识相当于简单可用性问题中 的 M ［AuthorityGrantingDecision ＞M′， 而 E（AuthorityGrantingDecision，tokens）＜if authority＞= policy then 1`（（subject，object，authority）::tokenlist）else 1`tokenlist＞=1`（（subject，object， authority）::tokenlist）则 表 明AuthorityGrantingDecision 变迁点火成功生成了一个token，因此无论后面的变迁点火序列是什么，最终都会到第21步，M20［AccessResources＞M21，使用token访问客体，唯一的不同在于有可能主体拿到token 直接自己使用，也有可能将token 传递给其他主体，由其他主体使用token。同时，通过cpn tools进行的仿真结果表示，BBIAC 模型满足简单可用性。因此模型在简单可用性问题方面是安全的。 证毕。

表3 典型的变迁点火序列Tab. 3 Typical transition firing sequence

3.3.3 约束继承问题

定义5 数据流。在任意变迁点火序列中，含有相同主体地址值的所有Petri_token，称之为相关的数据流。

数据流间接反映了与该主体相关的所有操作。

定义6 约束继承问题。对于标识序列中的任意主体产生 的 相 关 数 据 流，都 满 足subject. att≥token. att≥policy. att≥object.att，即属性约束在访问控制过程中是向下继承的，否则该模型就是不安全的。

证明

在BBIAC 的CPN 模型中，∀subject. add∈subjectAddress。对于模型中所有与subject.add 相关的数据，其对应的属性由变迁的防卫函数或者弧表达式约束。

首先在替代变迁RequestAccess 的子页模型中，由

E（Decision，results）＜if attri＞=authority then 1`（object，authority）else 1`（0，0）＞确保了subject.att≥token.att，其中attri是subject的属性，authority为将来生成的token的属性。

然后，在替代变迁RegisteredObject 中，CollisionDetection变迁的防卫函数［attri ＜= policy］确保了policy.att≥object.att，这里attri是客体object的属性。

最后，在替代变迁TransferAccess 中，由Test变迁确保了模型在token 传递时其约束也是被继承下去的，即subjectto.att≥subjectfrom. att，本文将这个过程进行了适当的抽象简化，由Test变迁表示这个含义。

综上所述，在替代变迁RequestAccess 中确保了token.att≥policy. att 和 policy. att≥object. att，在 替 代 变 迁RegisteredObject 中确保了policy. att≥object. att，在替代变迁TransferAccess 中确保了subjectto.att≥subjectfrom.att。因此模型满足subject.att≥token.att≥policy.att≥object.att，在约束继承问题方面是安全的。 证毕。

4 性能分析与实验

在完成模型安全性的理论性证明后，这里通过实验验证BBIAC 框架确实可以满足物联网环境下海量性、动态性和设备轻量级特性的挑战。

4.1 海量性

分析BBIAC 框架对海量性的支持程度，因为区块链对海量性用户的支持并不是本文的工作，所以本实验仅反映模型架构对海量性的支持，其中将物联网规模的增加映射为访问控制策略数的增加。

策略数分别设为1 000、2 000、4 000、6 000、8 000、10 000，以此映射物联网中用户和设备不断增加。选择了以太坊和超级账本这两种区块链平台，分别对应了POW（Proof of Work）和PBFT（Practical Byzantine Fault Tolerance）两种共识算法。实验的内容是主体s1对客体o1进行20 次访问。每组进行20次实验取平均。实验中POW 和PBFT 的共识时间来自文献［25］，因为本实验搭建的区块链环境并不能客观地反映这两种共识算法的时间性能。

图11 为不同访问控制策略数下使用POW 和PBFT 共识算法的BBIAC 的第一次访问响应时间。图11 中黑色的其他开销中包括网络传播时间和客户端编译时间，每组的时间基本相同。由图11 可知影响访问控制响应时间的主要变量是决策时间，当策略数增加后，决策时间也会随之增加，决策时间会成为影响访问控制响应时间的主要因素。

选择访问决策同样是基于主体和客体属性的ABAC 作为对比对象，在策略数为10 000 时对比ABAC 和BBIAC 的响应时间和累计时间。

由图12可知:在第一次访问时ABAC所用时间最短，因为它没有区块链共识的时间。而BBIAC+POW 的响应时间是最长，因为它不仅需要访问决策而且还需要区块链共识，同时POW 共识所需的时间最长。BBIAC+PBFT 的响应时间比ABAC 略长但比BBIAC+POW 短，因为PBFT 共识所需的时间较POW 会短很多。而BBIAC+POW 和BBIAC+PBFT 在第一次访问后的访问响应时间都较短且平滑是因为在主体s1得到客体token 后，只需要进行算法4 的过程即可，即客体可以先授权后共识，这一过程较为简单。ABAC 响应时间的波动是因为每次实验初始化的策略和请求的客体都不同，因此会有误差。

图11 第一次访问控制的响应时间Fig. 11 Response time for first access control

图12 访问控制响应时间对比Fig. 12 Comparison of access control response time

同样由图13 可知，在策略数为10 000 时，仅第一次访问ABAC占微小的优势，随着token使用次数的增加，BBIAC累计时间大幅少于ABAC。

图13 访问控制累计时间Fig. 13 Cumulative time of access control

实验结果表明BBIAC 适用于物联网，尤其是拥有大规模节点、访问控制规则复杂的物联网。

4.2 动态性

当前场景下的狭义的动态性指的是由于物联网用户和设备移动造成的节点动态接入问题，这个问题在选择区块链作为访问控制搭建平台时就由区块链自身的特性解决了，因此这里的动态性指的是权限的动态传递。

设计三组实验，策略数设为1 000，实验场景为连续访问20 次，分别传递1 次、2 次和3 次token，传递发生在访问的第3、5、7次。策略数选择设为1 000而不是10 000是因为当策略数为10 000时数据无法体现动态性变化趋势。

使用POW 共识算法时累计访问花费的时间如图14 所示，传递1 次token 时在第9 次访问后BBIAC 的累计时间较开始比ABAC 短。共识算法使用PBFT 的实验中仅第一次访问ABAC占优，这是由于PBFT的共识时间较短。

token 传递为BBIAC 节省了决策的时间开销，在策略数较大的情况下节省的时间是很可观的。但是token 传递需要区块链共识，因此当token频繁传递时会导致多次共识时间增加了BBIAC的时间开销。

图14 权限多次传递对累计响应时间的影响Fig. 14 Impact of multiple permission transfers on cumulative response time

4.3 设备轻量级

这里只讨论物联网中的轻量级设备。例如各类传感器等设备，虽然作为数据源向网络中上传数据，但是其设备自身的物理性质使其无法直接连接在本模型中，而是需要一个管理节点。而更多的轻量级设备是有一定计算和存储能力的。因此，部分设备可以在其上部署以太坊客户端与以太坊网络中部署的BBIAC智能合约进行交互。

主流的区块链平台都支持轻量级客户端，如以太坊的imToken、MetaMask和Hyperledger的lroha等项目，因此物联网设备设备只要能够连接到网络即可发起交易。

BBIAC 模型将区块链作为访问决策的实体，可以满足物联网设备轻量级的挑战。

5 结语

本文提出了一种满足物联网海量性、动态性和设备轻量级的基于区块链的物联网访问控制框架。首先提出了形式化的BBIAC 模型设计，并详细介绍了模型的工作流程设计。然后通过CPN 证明了BBIAC 的安全性，首先为BBIAC 建立了CPN模型，然后通过CPN从简单安全问题、简单可用性问题和约束继承问题这三个方面证明了BBIAC 模型的安全性。最后通过实验验证了BBIAC满足其在设计时的目的。

我们的下一步工作是进一步细化本文所提出的框架，研究适用于物联网的多中心结构的属性挖掘和授予机制。