羅金喜，王 珺

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

0 引言

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

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

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

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

1.1 系統(tǒng)模型

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

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

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

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

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

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

1.2 安全模型

本文采用了文獻(xiàn)[6]中定義的訪問控制列表模型來實(shí)現(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è)計(jì)了一種適用于邊緣計(jì)算系統(tǒng)的訪問控制框架。該框架通過訪問控制列表ACL 模型實(shí)現(xiàn)訪問控制，而此模型的權(quán)限列表則由區(qū)塊鏈上的智能合約管理，因此可以解決傳統(tǒng)訪問控制中的集中化問題。

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

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

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

2.1.1 ACC合約

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

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

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

2.1.2 ACP合約

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

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

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

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

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

2.1.3 AUD合約

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

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

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

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

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

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

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

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

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

數(shù)據(jù)請求者隨后向第三方服務(wù)器發(fā)送一個請求，該請求包含所需數(shù)據(jù)對象ID、自身公鑰以及對訪問所需的相關(guān)數(shù)據(jù)的簽名(數(shù)字簽名使用ECDSA)。第三方服務(wù)器可以通過提供的公鑰驗(yàn)證用戶的身份，如果簽名是有效的，那么將繼續(xù)驗(yàn)證用戶的訪問權(quán)限。它向區(qū)塊鏈發(fā)送一個交易，以執(zhí)行ACP合約validateRight函數(shù)來驗(yàn)證訪問權(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é)點(diǎn)發(fā)起密鑰請求，該請求包含上述數(shù)字簽名和預(yù)定義的消息。密鑰分發(fā)節(jié)點(diǎn)中的Enclave 程序首先通過數(shù)字簽名驗(yàn)證消息的完整性，如果有效，且當(dāng)前的系統(tǒng)時間小于截止時間，則證明該用戶擁有訪問權(quán)。然后根據(jù)中的請求數(shù)據(jù)的索引數(shù)據(jù)所有者存入的解密密鑰，并用數(shù)據(jù)請求者的公鑰PK對其進(jìn)行加密，將結(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í)行階段的額外開銷進(jìn)行擴(kuò)展性分析。在初始化階段，所有的額外開銷和以下操作有關(guān)系：智能合約被創(chuàng)建/部署到區(qū)塊鏈、對Enclave 進(jìn)行遠(yuǎn)程認(rèn)證并傳入解密密鑰和用AES-128 算法對原始數(shù)據(jù)進(jìn)行加密。其中前兩個操作的時間花銷與共享數(shù)據(jù)的大小無關(guān)，在一個固定值附近波動，而最后一個操作與共享數(shù)據(jù)的大小有著緊密的關(guān)系，本文在個人電腦上使用AES-128 算法進(jìn)行了性能測試，結(jié)果如圖5所示，加密時間隨著共享數(shù)據(jù)的大小增加而線性增加，滿足擴(kuò)展性要求，而每一份共享的數(shù)據(jù)對象只需要初始化一次，因此本文提出的方案的初始化開銷是可以接受的。

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

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

4 結(jié)束語

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