羅金喜，王 珺

(南京郵電大學(xué)通信與信息工程學(xué)院，江蘇 南京 210003)

0 引言

邊緣計算作為5G 時代的核心技術(shù)之一，通過將終端設(shè)備的數(shù)據(jù)放入邊緣服務(wù)器以進行存儲或計算，可以解決終端存儲容量有限、計算能力不足的問題。邊緣計算系統(tǒng)中的邊緣服務(wù)器節(jié)點是眾多終端的匯聚點，這些終端包括智能移動終端、傳感器、攝像頭等物聯(lián)網(wǎng)設(shè)備。若將終端收集、產(chǎn)生或存儲的一些數(shù)據(jù)共享，那么數(shù)據(jù)資源將得到最大化利用。

然而邊緣網(wǎng)絡(luò)中不同個體或機構(gòu)間缺乏合作的保障和信任關(guān)系，難以形成安全可靠的數(shù)據(jù)共享局面，因此急需一個適用于邊緣網(wǎng)絡(luò)的訪問控制機制。傳統(tǒng)的訪問控制策略包括基于角色的訪問控制（Role-Based Access Control，RBAC）、基于屬性的訪問控制(Attribute Based Access Control，ABAC）和基于風(fēng)險的訪問控制(Risk Based Access Control，Risk-BAC)。上述訪問控制方案均通過一個權(quán)威的中心機構(gòu)來驗證訪問權(quán)，因此面臨著中心化所帶來的問題，即可能發(fā)生單點故障。而且訪問控制有三個重要的安全要素：認證、授權(quán)和審計，如果由一個中心服務(wù)器來提供訪問控制，那么惡意的中心服務(wù)器可能會認證、授權(quán)不具有相關(guān)權(quán)限的用戶，從而導(dǎo)致數(shù)據(jù)泄露問題。審計負責(zé)記錄系統(tǒng)中所有已發(fā)生的訪問控制事件，如果中心服務(wù)器擁有對審計的完全控制權(quán)，則很難防范惡意的服務(wù)器篡改審計數(shù)據(jù)。

為了解決上述問題，本文利用區(qū)塊鏈上的智能合約來管理訪問權(quán)限和審計數(shù)據(jù)，依賴于區(qū)塊鏈的去中心化和不可篡改特性解決單點故障和節(jié)點信任問題。為了保證數(shù)據(jù)的隱私性，上傳到第三方服務(wù)器上的共享數(shù)據(jù)采用AES-128 算法加密，而解密密鑰則通過SGX(Software Guard Extensions)技術(shù)構(gòu)建安全程序進行共享。

1 系統(tǒng)模型和安全模型

1.1 系統(tǒng)模型

如圖1 所示，本文所考慮的邊緣計算系統(tǒng)由云服務(wù)器、邊緣服務(wù)器和眾多終端組成。由于本文方案的底層區(qū)塊鏈網(wǎng)路為以太坊，而以太坊是一種公有區(qū)塊鏈，任何節(jié)點可以隨時加入和退出網(wǎng)絡(luò)，因此邊緣計算系統(tǒng)中的任意設(shè)備均可成為區(qū)塊鏈節(jié)點。本文根據(jù)上述各元素在訪問控制中的作用，將其分為以下角色：數(shù)據(jù)所有者、第三方服務(wù)器、區(qū)塊鏈網(wǎng)絡(luò)和數(shù)據(jù)請求者。

圖1 邊緣計算系統(tǒng)架構(gòu)

共享數(shù)據(jù)的擁有者，可以是網(wǎng)絡(luò)中的任意節(jié)點。

主要由邊緣服務(wù)器和云服務(wù)器組成，為數(shù)據(jù)共享提供存儲和計算資源，本方案的存儲模式也是分布式的，數(shù)據(jù)所有者可以自由選擇系統(tǒng)中注冊的服務(wù)器作為存儲數(shù)據(jù)的第三方服務(wù)器。

包含交易和智能合約的區(qū)塊鏈，由邊緣網(wǎng)絡(luò)中所有設(shè)備共同維護，任意節(jié)點可根據(jù)業(yè)務(wù)需要靈活地加入。

是共享數(shù)據(jù)的請求者。

1.2 安全模型

本文采用了文獻[6]中定義的訪問控制列表模型來實現(xiàn)權(quán)限管理。訪問控制列表(Access Control List，ACL)模型是一種以對象為中心的方法，為每個對象O定義了一個列表L，即O 的訪問控制權(quán)，這個列表列舉了所有擁有O 的訪問權(quán)限的主體，這個列表還指定了授予主體的訪問權(quán)限（例如，讀和寫）。為了將ACL 映射到我們的方案，對于每個對象O，也就是存儲在第三方服務(wù)器上的數(shù)據(jù)，本文定義了如表1所示的列表，記錄主體(數(shù)據(jù)請求者)所擁有的權(quán)限的相關(guān)信息。這個列表存儲在區(qū)塊鏈中。

表1 訪問控制列表

2 一種基于區(qū)塊鏈的訪問控制框架

本文基于區(qū)塊鏈技術(shù)設(shè)計了一種適用于邊緣計算系統(tǒng)的訪問控制框架。該框架通過訪問控制列表ACL 模型實現(xiàn)訪問控制，而此模型的權(quán)限列表則由區(qū)塊鏈上的智能合約管理，因此可以解決傳統(tǒng)訪問控制中的集中化問題。

區(qū)塊鏈上資源寶貴，因此共享數(shù)據(jù)需存儲到第三方服務(wù)器，為了防止第三方服務(wù)器泄漏數(shù)據(jù)，本方案將數(shù)據(jù)的共享分割為兩部分，即加密數(shù)據(jù)和解密密鑰的共享方式并不相同。第三方服務(wù)器通過執(zhí)行以太坊合約驗證請求者訪問權(quán)限，根據(jù)返回結(jié)果決定加密數(shù)據(jù)的共享，而解密密鑰則通過SGX技術(shù)進行管理。

2.1 智能合約系統(tǒng)框架

本文提出的智能合約框架包含三種合約，ACC 合約、ACP合約和AUD合約。

2.1.1 ACC合約

對于數(shù)據(jù)所有者而言，該合約是ACP 合約的生產(chǎn)工廠，即ACP 合約只能通過調(diào)用ACC 合約提供的createACP 函數(shù)進行部署。而數(shù)據(jù)請求者則可以通過數(shù)據(jù)對象的唯一id 索引所需的相關(guān)信息，包括ACP 合約地址、原始數(shù)據(jù)hash摘要(數(shù)據(jù)請求者用于驗證解密后數(shù)據(jù)的正確性)、密鑰分發(fā)節(jié)點、第三方服務(wù)器等。該合約主要包含以下幾個函數(shù)。

●createACP：該函數(shù)接受數(shù)據(jù)對象的相關(guān)參數(shù)，并在區(qū)塊鏈上部署一個ACP 合約，同時把相應(yīng)的信息存入此合約維護的列表中。

●retrieveObject：該函數(shù)接受數(shù)據(jù)對象ID，返回獲取數(shù)據(jù)所需的相關(guān)信息。

2.1.2 ACP合約

該合約用于管理數(shù)據(jù)對象的訪問權(quán)限。每個ACP 合約中都維護著一個列表，結(jié)構(gòu)如表1 所示。該列表記錄了其他終端用戶的訪問權(quán)限，其中許可字段存儲的是數(shù)字簽名(用于在Enclave程序中驗證請求者對對稱密鑰的獲取權(quán)限)，第三方服務(wù)器通過判斷返回的許可是否為零來決定用戶的訪問權(quán)。

ACP 合約所有者可以對訪問控制列表的內(nèi)容進行增刪改查的操作；第三方服務(wù)器可以通過交易發(fā)起驗證用戶權(quán)限的請求，相應(yīng)的訪問日志會被記錄在AUD 合約中。合約所有者地址、第三方服務(wù)器地址等屬性由合約的構(gòu)造函數(shù)進行初始化。ACP 主要提供了以下函數(shù)來管理訪問控制。

●addRight：該函數(shù)接收新的訪問控制策略信息，并將此項控制策略添加到訪問控制列表中。

●updateRight：該函數(shù)接收需要更新的策略信息，并更新訪問控制列表中的策略。

●validateRight：該函數(shù)接收訪問控制所需的信息，返回訪問結(jié)果，同時調(diào)用AUD 合約中的setLog 函數(shù)，將此次訪問信息存儲到日志中。

2.1.3 AUD合約

該合約由ACP 合約的構(gòu)造函數(shù)部署到區(qū)塊鏈上。AUD 合約維護一個審計所需信息的列表，此列表是為了將數(shù)據(jù)使用情況存儲到區(qū)塊鏈上進行審計。該合約包含以下幾個函數(shù)。

●accessLog：該函數(shù)接收數(shù)據(jù)訪問者公鑰，并返回該訪問者的歷史訪問日志。

●setLog：該函數(shù)接收訪問日志信息，并將此日志信息的情況存入AUD合約維護的審計列表中。

2.2 接入控制

整個接入控制過程可分為共享數(shù)據(jù)上傳和共享數(shù)據(jù)下載兩部分。

2.2.1 共享數(shù)據(jù)上傳

首先數(shù)據(jù)所有者通過交易執(zhí)行區(qū)塊鏈上的ACC合約中的createACP 函數(shù)，將共享數(shù)據(jù)注冊，并部署管理該共享數(shù)據(jù)訪問控制的ACP 合約，ACP 合約初始化時也會部署一個記錄日志信息的AUD合約，最后將返回ACP合約地址給數(shù)據(jù)所有者。

為了保障數(shù)據(jù)的隱私性，本方案中在將數(shù)據(jù)上傳到第三方服務(wù)器前，首先需要對其進行加密。為了降低加密、解密數(shù)據(jù)所消耗的計算資源，本文采用對稱加密技術(shù)，即數(shù)據(jù)所有者隨機選擇一個128 位的加密密鑰，并使用AES-128 算法對數(shù)據(jù)進行加密。然后，數(shù)據(jù)所有者將加密的數(shù)據(jù)與ACP 合約地址一起發(fā)送給第三方服務(wù)器。發(fā)送ACP 合約的地址是為了讓第三方服務(wù)器調(diào)用并執(zhí)行該合約的validateRight 函數(shù)，以驗證數(shù)據(jù)請求者的訪問權(quán)限。同時第三方服務(wù)器還要獲得ACP 合約的所有者公鑰，以此驗證數(shù)據(jù)所有者的簽名。如果簽名有效，第三方服務(wù)器將把已加密的數(shù)據(jù)存儲到他們的設(shè)備中。

圖2 數(shù)據(jù)上傳流程

數(shù)據(jù)成功上傳到第三方存儲服務(wù)器后，數(shù)據(jù)所有者通過英特爾認證服務(wù)（Intel Authentication Service，IAS）驗證密鑰分發(fā)節(jié)點中實例化的Enclave 的完整性，包括內(nèi)部數(shù)據(jù)和代碼。此外，驗證報告還包含Enclave產(chǎn)生的公鑰，數(shù)據(jù)所有者用該公鑰加密需分發(fā)的對稱密鑰，從而保證其安全地傳入了Enclave中。為了保證系統(tǒng)的魯棒性，應(yīng)該有多個密鑰分發(fā)節(jié)點，以確保在任何時間內(nèi)系統(tǒng)都能正常工作。

2.2.2 共享數(shù)據(jù)下載

當(dāng)數(shù)據(jù)請求者需要訪問某項數(shù)據(jù)時，為了保證數(shù)據(jù)的安全性，首先調(diào)用ACC 合約中的retrieveObject 函數(shù)，根據(jù)數(shù)據(jù)唯一ID 獲得實現(xiàn)訪問所需的相關(guān)信息，如第三方服務(wù)器地址、密鑰分發(fā)節(jié)點和原始數(shù)據(jù)hash摘要。

圖3 數(shù)據(jù)下載流程

數(shù)據(jù)請求者隨后向第三方服務(wù)器發(fā)送一個請求，該請求包含所需數(shù)據(jù)對象ID、自身公鑰以及對訪問所需的相關(guān)數(shù)據(jù)的簽名(數(shù)字簽名使用ECDSA)。第三方服務(wù)器可以通過提供的公鑰驗證用戶的身份，如果簽名是有效的，那么將繼續(xù)驗證用戶的訪問權(quán)限。它向區(qū)塊鏈發(fā)送一個交易，以執(zhí)行ACP合約validateRight函數(shù)來驗證訪問權(quán)，如果返回的是非零的數(shù)字簽名，則表明用戶有權(quán)訪問數(shù)據(jù)，那么就會向用戶提供加密的數(shù)據(jù)和返回的數(shù)字簽名，此數(shù)字簽名是數(shù)據(jù)所有者對預(yù)定義消息(根據(jù)消息結(jié)構(gòu)生成)的簽名，該消息結(jié)構(gòu)如表2所示。

表2 預(yù)定義消息結(jié)構(gòu)

為了解密第三方服務(wù)器傳來的數(shù)據(jù)，數(shù)據(jù)請求者向密鑰分發(fā)節(jié)點發(fā)起密鑰請求，該請求包含上述數(shù)字簽名和預(yù)定義的消息。密鑰分發(fā)節(jié)點中的Enclave 程序首先通過數(shù)字簽名驗證消息的完整性，如果有效，且當(dāng)前的系統(tǒng)時間小于截止時間，則證明該用戶擁有訪問權(quán)。然后根據(jù)中的請求數(shù)據(jù)的索引數(shù)據(jù)所有者存入的解密密鑰，并用數(shù)據(jù)請求者的公鑰PK對其進行加密，將結(jié)果返回數(shù)據(jù)請求者，Enclave 程序的具體流程如圖4 所示。最終數(shù)據(jù)請求者通過自己的私鑰解密傳回的結(jié)果獲得解密密鑰。

圖4 Enclave程序流程圖

3 性能分析

此方案的性能高度依賴于底層區(qū)塊鏈平臺，區(qū)塊鏈系統(tǒng)的hash 算力、網(wǎng)絡(luò)架構(gòu)、智能合約的復(fù)雜性、任務(wù)數(shù)量、區(qū)塊生成率和網(wǎng)絡(luò)帶寬都將極大地影響了此方案的性能。

因此本節(jié)主要對初始化階段和執(zhí)行階段的額外開銷進行擴展性分析。在初始化階段，所有的額外開銷和以下操作有關(guān)系：智能合約被創(chuàng)建/部署到區(qū)塊鏈、對Enclave 進行遠程認證并傳入解密密鑰和用AES-128 算法對原始數(shù)據(jù)進行加密。其中前兩個操作的時間花銷與共享數(shù)據(jù)的大小無關(guān)，在一個固定值附近波動，而最后一個操作與共享數(shù)據(jù)的大小有著緊密的關(guān)系，本文在個人電腦上使用AES-128 算法進行了性能測試，結(jié)果如圖5所示，加密時間隨著共享數(shù)據(jù)的大小增加而線性增加，滿足擴展性要求，而每一份共享的數(shù)據(jù)對象只需要初始化一次，因此本文提出的方案的初始化開銷是可以接受的。

圖5 加/解密開銷與文件大小的關(guān)系

在執(zhí)行階段，所有的額外開銷由訪問權(quán)驗證交易、從Enclave中獲取解密密鑰和用對稱密鑰解密數(shù)據(jù)的時間組成。其中，交易完成時間由區(qū)塊鏈的區(qū)塊生成時間決定，又解密密鑰固定為128位，即正常網(wǎng)絡(luò)情況下密鑰請求時間基本固定，最終的數(shù)據(jù)解密時間與文件的大小關(guān)系為圖5 所示的線性關(guān)系，滿足擴展性要求。綜上，相對于現(xiàn)有的集中式數(shù)據(jù)共享平臺，本方案雖然會有性能上的損失，但總體時間成本可控，能夠滿足大型數(shù)據(jù)共享的要求。

4 結(jié)束語

本文針對邊緣計算網(wǎng)絡(luò)中數(shù)據(jù)共享的隱私、信任和單點故障的挑戰(zhàn)，提出了一個基于智能合約的方案，該方案可以為邊緣計算系統(tǒng)提供一個去中心化的訪問控制機制。而且根據(jù)上述的性能分析可知，相對于傳統(tǒng)的數(shù)據(jù)共享系統(tǒng)，本文提出的方案雖然在性能上有一定損失，但安全性卻大大增加，能抵抗惡意的服務(wù)提供商攻擊和中間人攻擊。本方案的性能高度依賴于底層區(qū)塊鏈平臺，因此，下一步重點研究的內(nèi)容是探索適合該方案框架的區(qū)塊鏈擴容技術(shù)，進一步提高方案的實用性。