基于區塊鏈的物聯網訪問控制框架

史錦山，李 茹*，松婷婷

（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滿足其在設計時的目的。

我們的下一步工作是進一步細化本文所提出的框架，研究適用于物聯網的多中心結構的屬性挖掘和授予機制。