◆秦永寧

一種對(duì)等網(wǎng)絡(luò)安全通信方案研究

◆秦永寧

（審計(jì)署審計(jì)干部教育學(xué)院 江蘇 211815）

為增強(qiáng)P2P網(wǎng)絡(luò)傳輸過(guò)程和傳輸數(shù)據(jù)的安全性，本文借助于TEE（可信執(zhí)行環(huán)境）技術(shù)，提出一種對(duì)等網(wǎng)絡(luò)安全通信方案，為數(shù)據(jù)處理和終端認(rèn)證提供了可信執(zhí)行環(huán)境，保證敏感數(shù)據(jù)傳輸過(guò)程的安全性并防止終端被冒充。最終證明了此方案所提技術(shù)和方法的有效性，可以滿足P2P網(wǎng)絡(luò)信息交互的安全需求。

P2P；TrustZone；可信執(zhí)行環(huán)境；通信安全

隨著智能設(shè)備特別是移動(dòng)終端的發(fā)展普及，人們獲取信息和處理事務(wù)的方式漸漸由PC端轉(zhuǎn)移到移動(dòng)終端，現(xiàn)有移動(dòng)設(shè)備操作系統(tǒng)的開(kāi)放性無(wú)法保證設(shè)備的安全。備受關(guān)注近距離無(wú)線組網(wǎng)技術(shù)能有效地利用網(wǎng)絡(luò)的異構(gòu)性，避免中心化服務(wù)器帶來(lái)的性能瓶頸、單點(diǎn)失效等問(wèn)題。如何保障數(shù)據(jù)傳輸、終端乃至整個(gè)網(wǎng)絡(luò)的安全是對(duì)等網(wǎng)絡(luò)（P2P）機(jī)構(gòu)發(fā)展推廣的關(guān)鍵。

本方案旨在提高P2P通信過(guò)程的安全性，方案以AllJoyn框架、TrustZone技術(shù)和可信操作系統(tǒng)T-OS為基礎(chǔ)，將ARM TrustZone安全擴(kuò)展機(jī)制與對(duì)等網(wǎng)絡(luò)技術(shù)相結(jié)合，為敏感數(shù)據(jù)的處理和傳輸提供了更好的安全性，滿足信息交互的安全需求，切實(shí)保障數(shù)據(jù)的安全。

1 基于AllJoyn的可信對(duì)等通信方案

在AllJoyn和TEE的環(huán)境搭建的基礎(chǔ)上，將TEE的數(shù)據(jù)存儲(chǔ)和處理模塊的功能與AllJoyn的廣播和發(fā)現(xiàn)服務(wù)、身份認(rèn)證、會(huì)話綁定、對(duì)等機(jī)信息和解析相關(guān)協(xié)議相結(jié)合，設(shè)計(jì)了一個(gè)基于AllJoyn的可信對(duì)等通信方案。并將方案功能拆分為兩個(gè)大模塊，用戶安全管理模塊和數(shù)據(jù)加解密模塊。在用戶安全管理模塊中，設(shè)計(jì)了服務(wù)動(dòng)態(tài)接入和動(dòng)態(tài)離線組件，并使用流程圖對(duì)核心的身份認(rèn)證協(xié)議做了詳細(xì)介紹。在數(shù)據(jù)加解密模塊中，以加密過(guò)程為例，闡述了客戶端應(yīng)用如何使用TEE安全服務(wù)對(duì)數(shù)據(jù)進(jìn)行安全可靠的密碼運(yùn)算。

1.1 系統(tǒng)總體方案

如圖1所示，本方案按照功能可劃分為兩大模塊：用戶安全管理和數(shù)據(jù)安全傳輸模塊。兩個(gè)模塊建立在AllJoyn模塊之上，并通過(guò)系統(tǒng)管理模塊提供給用戶。用戶安全管理模塊中，在使用已知的AllJoyn會(huì)話接口（AdvertiseName API等）的基礎(chǔ)上，通過(guò)調(diào)用REE客戶端API，繼而調(diào)用TEE安全存儲(chǔ)和加密API，設(shè)計(jì)出一個(gè)對(duì)可信終端的認(rèn)證模塊，實(shí)現(xiàn)在終端通信過(guò)程中加入對(duì)可信終端的認(rèn)證，在可信客戶端申請(qǐng)加入會(huì)話、終端連接會(huì)話、服務(wù)端接受會(huì)話直到成功建立會(huì)話的過(guò)程中保證終端的不可偽造和密鑰安全。數(shù)據(jù)安全傳輸模塊中，使用TEE存儲(chǔ)和加密API進(jìn)行數(shù)據(jù)在終端的處理，并使用MyBusObject類API進(jìn)行數(shù)據(jù)傳輸。下面將對(duì)兩大模塊中具有代表性的子模塊的工作過(guò)程進(jìn)行描述。

圖1 系統(tǒng)詳細(xì)設(shè)計(jì)圖

1.2 用戶安全管理模塊設(shè)計(jì)

1.2.1會(huì)話機(jī)制

當(dāng)客戶端希望定位并尋求一個(gè)服務(wù)時(shí)，它會(huì)向后臺(tái)路由發(fā)出查詢名稱的請(qǐng)求，同理，該客戶端所在的路由會(huì)在客戶端輸入的基礎(chǔ)上，確認(rèn)查詢和探測(cè)廣播的最佳方式。當(dāng)設(shè)備移動(dòng)到彼此的臨近區(qū)域時(shí)，它們會(huì)通過(guò)可能的方式來(lái)監(jiān)聽(tīng)其他設(shè)備的廣播消息和發(fā)現(xiàn)請(qǐng)求。圖2描述了客戶端發(fā)現(xiàn)服務(wù)的流程。

圖2 客戶端發(fā)現(xiàn)服務(wù)流程

（1）服務(wù)端向本地路由發(fā)送廣播請(qǐng)求；

（2）后臺(tái)路由根據(jù)服務(wù)端的輸入，決定應(yīng)該采用網(wǎng)絡(luò)中哪種具體的機(jī)制來(lái)進(jìn)行廣播并付諸實(shí)施；

（3）支持該服務(wù)的路由發(fā)現(xiàn)請(qǐng)求和給出響應(yīng)；

（4）客戶端接到提示，在該區(qū)域發(fā)現(xiàn)了一個(gè)可以提供所期望的服務(wù)的路由。

上圖所示的客戶端和服務(wù)端雙方都是通過(guò)總線附件的方法和回調(diào)，來(lái)實(shí)現(xiàn)廣播和發(fā)現(xiàn)過(guò)程。服務(wù)端會(huì)通過(guò)創(chuàng)建總線對(duì)象來(lái)提供服務(wù)，而客戶端則希望通過(guò)代理對(duì)象來(lái)提供一個(gè)易于和服務(wù)端進(jìn)行通信的接口。代理對(duì)象將使用AllJoyn中的ProxyBusObject來(lái)協(xié)調(diào)與服務(wù)端的通信，并提供方法參數(shù)和返回值的序列化和反序列化處理。

在調(diào)用遠(yuǎn)端方法前，必須建立一個(gè)通信會(huì)話來(lái)有效連接不同的總線線段。廣播和發(fā)現(xiàn)機(jī)制不同于會(huì)話，終端設(shè)備可以接收廣播而不采取任何響應(yīng)，只有當(dāng)設(shè)備接收到廣播，并且決定加入通信會(huì)話時(shí)，廣播設(shè)備和接收設(shè)備的總線才會(huì)從邏輯上連接為一體。為了實(shí)現(xiàn)這個(gè)功能，服務(wù)端必須建立通信會(huì)話的終端并廣播它的存在，客戶端必須能接收到這些廣播，并請(qǐng)求加入該會(huì)話。服務(wù)端在廣播服務(wù)前必須定義一個(gè)半連接，如下所示：

{reliable IP messages（可靠的IP消息），org. alljoyn. samples. chat.1（well-known名稱），42（端口號(hào)）}

這表明服務(wù)將通過(guò)可靠的消息傳輸信道與客戶端指定名稱的總線和會(huì)話端口號(hào)進(jìn)行通信，我們創(chuàng)建一個(gè)具有特定名稱：2.1的總線附件，該總線附件希望與另一個(gè)位于其他設(shè)備的路由連接，那么它將向該路由所在的系統(tǒng)提供這份半連接信息，成功連接后，系統(tǒng)會(huì)分配一個(gè)新的會(huì)話ID來(lái)進(jìn)行具體的通信，如下所示：

{reliable IP messages，org.alljoyn.samples.chat.1，：2.1，1025}

名為org.alljoyn.samples.chat.1（服務(wù)）的總線附件和名為：2.1（客戶端）的總線附件之間會(huì)形成新的通信會(huì)話，該會(huì)話使用基于IP協(xié)議棧的可靠消息傳遞協(xié)議來(lái)進(jìn)行。用來(lái)描述會(huì)話的會(huì)話ID是由要連接的后臺(tái)路由系統(tǒng)分配的，在上面的描述中，會(huì)話ID便是1025。

為了實(shí)現(xiàn)最終端到端的通信會(huì)話，借助AllJoyn采取了一切可行的操作方式來(lái)建立虛擬軟件總線，在實(shí)際通信過(guò)程中可以做到的是，一個(gè)Wi-Fi Direct的點(diǎn)對(duì)點(diǎn)連接用來(lái)支持一個(gè)TCP連接，無(wú)線接入點(diǎn)用來(lái)承載UDP連接，一個(gè)藍(lán)牙微網(wǎng)用來(lái)支持L2CAP連接，決定于所提供的會(huì)話選項(xiàng)，滿足不同的會(huì)話要求。考慮到安全問(wèn)題，需要客戶端和服務(wù)端在這一階段對(duì)身份進(jìn)行驗(yàn)證，完成這些步驟后，客戶端和服務(wù)繼續(xù)進(jìn)行RMI通信。

1.2.2服務(wù)動(dòng)態(tài)接入組件設(shè)計(jì)

基礎(chǔ)服務(wù)層中的設(shè)備由動(dòng)態(tài)接入模塊與應(yīng)用層程序按照AllJoyn即插即用的通信協(xié)議進(jìn)行信息交換，完成業(yè)務(wù)環(huán)境中服務(wù)單元的發(fā)現(xiàn)、認(rèn)證、注冊(cè)、維護(hù)等相關(guān)工作。服務(wù)動(dòng)態(tài)接入的會(huì)話機(jī)制包括動(dòng)態(tài)接入與動(dòng)態(tài)離線兩部分，會(huì)話過(guò)程設(shè)計(jì)如圖3，圖4所示。

圖3 動(dòng)態(tài)接入

圖3表示一個(gè)點(diǎn)對(duì)點(diǎn)AllJoyn會(huì)話建立消息流，步驟描述如下：

（1）服務(wù)端和消費(fèi)端應(yīng)用通過(guò)AllJoyn核心庫(kù)與各自的AllJoyn路由相連，并得到一個(gè)分配的unique名稱。

（2）服務(wù)端應(yīng)用通過(guò)AllJoyn核心庫(kù)注冊(cè)服務(wù)總線對(duì)象。

（3）服務(wù)端應(yīng)用通過(guò)AllJoyn核心庫(kù)從AllJoyn路由中請(qǐng)求一個(gè)well-known名稱。

（4）服務(wù)端通過(guò)AllJoyn核心庫(kù)的BindSessionPort API與AllJoyn路由綁定一個(gè)會(huì)話端口，這個(gè)調(diào)用為這次會(huì)話制定了會(huì)話端口、會(huì)話選項(xiàng)以及一個(gè)SessionPortListener。

（5）服務(wù)端應(yīng)用通過(guò)調(diào)用AllJoyn核心庫(kù)的AdvertiseName API由AllJoyn路由廣播其well-known名稱。

（6）服務(wù)端為well-known名稱開(kāi)啟一個(gè)特定傳輸廣播。

（7）消費(fèi)端應(yīng)用通過(guò)AllJoyn核心庫(kù)的FindAdvertiseName API查詢相同的well-known名稱。

（8）消費(fèi)端AllJoyn路由為了發(fā)現(xiàn)所需well-known名稱執(zhí)行特定傳輸查詢，即發(fā)送一個(gè)FoundAdvertiseName信號(hào)到消費(fèi)端應(yīng)用。

（9）消費(fèi)端應(yīng)用通過(guò)JoinSession API加入到服務(wù)端的會(huì)話中，此次調(diào)用指定了會(huì)話主機(jī)的unique Name、會(huì)話端口、期望的會(huì)話選項(xiàng)以及一個(gè)SessionListener。

（10）消費(fèi)端AllJoyn路由與服務(wù)端路由建立一個(gè)可用物理信道。

（11）一旦兩個(gè)AllJoyn總線間的連接建立，消費(fèi)端AllJoyn路由啟動(dòng)BusHello信息來(lái)發(fā)送其總線GUID和AllJoyn協(xié)議版本。服務(wù)端AllJoyn路由回復(fù)其GUID、AllJoyn協(xié)議版本和unique Name。

（12）消費(fèi)端和服務(wù)端AllJoyn路由發(fā)送ExchangeNames信號(hào)交換unique名稱/well-known名稱。

（13）消費(fèi)端AllJoyn路由請(qǐng)求服務(wù)端AllJoyn路由里的AttachSession方法調(diào)用來(lái)加入會(huì)話，這個(gè)調(diào)用指定了會(huì)話主機(jī)的會(huì)話端口、會(huì)話選項(xiàng)和unique/well-known名稱等參數(shù)。

（14）服務(wù)端AllJoyn路由通過(guò)服務(wù)端應(yīng)用請(qǐng)求一個(gè)AcceptSession方法調(diào)用，如果會(huì)話被接受將返回‘true’。

（15）服務(wù)端AllJoyn路由會(huì)為此次會(huì)話生成一個(gè)特定的會(huì)話ID，通過(guò)向消費(fèi)端AllJoyn路由發(fā)送一個(gè)AttachSession響應(yīng)消息來(lái)提供會(huì)話ID。

（16）服務(wù)端AllJoyn路由發(fā)送一個(gè)SessionJoined信號(hào)到Provider應(yīng)用指定會(huì)話ID。

（17）在接收到AttachSession回復(fù)之后，消費(fèi)端AllJoyn路由發(fā)送一個(gè)包含OK狀態(tài)的JoinSession回復(fù)消息到應(yīng)用并提供會(huì)話ID。

當(dāng)建立一個(gè)多點(diǎn)會(huì)話時(shí)，多點(diǎn)會(huì)話和點(diǎn)對(duì)點(diǎn)會(huì)話的消息流基本一樣，AllJoyn路由向應(yīng)用程序指定的新成員發(fā)送一個(gè)MPSessionChanged信號(hào)，這個(gè)信號(hào)指定了參與者的會(huì)話ID、unique Name、well-known名稱以及一個(gè)flag去指定該成員是否被添加進(jìn)來(lái)。一個(gè)新的消費(fèi)端加入多點(diǎn)會(huì)話時(shí)，新的加入者向所有現(xiàn)有成員調(diào)用一個(gè)AttachSession，現(xiàn)有的成員會(huì)將新加入者添加到它們會(huì)話相關(guān)的表格中，更新它們的會(huì)話節(jié)點(diǎn)信息來(lái)包含新加入者。

圖4 動(dòng)態(tài)離線

圖4表示消費(fèi)者離開(kāi)點(diǎn)對(duì)點(diǎn)會(huì)話消息流，會(huì)話被終止并從會(huì)話表格中移除。一個(gè)參與者通過(guò)在AllJoyn路由啟動(dòng)一個(gè)LeaveSession調(diào)用離開(kāi)會(huì)話，這導(dǎo)致DetachSession信號(hào)被發(fā)送到會(huì)話里的其他成員，其他成員收到這個(gè)信號(hào)觸發(fā)器會(huì)清除會(huì)話ID以及從會(huì)話表格中清除相關(guān)信息。當(dāng)會(huì)話終止時(shí)，一個(gè)SessionLost信號(hào)會(huì)發(fā)送給應(yīng)用。

消息流的步驟如下：

（1）消費(fèi)端應(yīng)用與會(huì)話主機(jī)建立一個(gè)會(huì)話。

（2）消費(fèi)端應(yīng)用決定離開(kāi)會(huì)話，通過(guò)AllJoyn核心庫(kù)從AllJoyn路由調(diào)用LeaveSession API，這個(gè)調(diào)用將會(huì)話ID作為輸入?yún)?shù)。

（3）AllJoyn路由產(chǎn)生一個(gè)DetachSession信號(hào)指定會(huì)話ID以及離開(kāi)會(huì)話的成員，此信號(hào)被發(fā)送給會(huì)話中的其他成員。

（4）在接收到DetachSession信號(hào)之后，會(huì)話主機(jī)處的AllJoyn路由確定其是唯一一個(gè)離開(kāi)會(huì)話的成員，由此給出結(jié)論是會(huì)話已經(jīng)終止并將會(huì)話ID信息從會(huì)話表格中清除。

（5）消費(fèi)端的AllJoyn路由清除其會(huì)話ID信息并發(fā)送一個(gè)成功的LeaveSession回復(fù)給應(yīng)用。

（6）會(huì)話主機(jī)端的AllJoyn路由發(fā)送一個(gè)SessionLost信號(hào)給應(yīng)用來(lái)指明會(huì)話已經(jīng)終止。

當(dāng)消費(fèi)端離開(kāi)一個(gè)超過(guò)兩個(gè)參與者的多點(diǎn)會(huì)話的信息流時(shí)，在這個(gè)場(chǎng)景下，即使一個(gè)成員離開(kāi)會(huì)話，剩下的參與者也會(huì)繼續(xù)，剩下的參與者更新其會(huì)話表格來(lái)移除已經(jīng)離開(kāi)會(huì)話的成員。而當(dāng)一個(gè)服務(wù)端（會(huì)話主機(jī)）離開(kāi)一個(gè)超過(guò)兩個(gè)參與者的多點(diǎn)會(huì)話的信息流時(shí)，在這種情況下，會(huì)話會(huì)繼續(xù)存在并且剩下的參與者可以相互通信，然而新的參與者不能加入到這個(gè)多點(diǎn)會(huì)話。

服務(wù)動(dòng)態(tài)接入的基礎(chǔ)程序作為連接動(dòng)態(tài)接入組件和底層AllJoyn系統(tǒng)的中間件，主要負(fù)責(zé)網(wǎng)絡(luò)通信和會(huì)話機(jī)制。在AllJoyn中，包含通信和會(huì)話在內(nèi)的所有機(jī)制的配置文檔都是XML格式的文檔，標(biāo)識(shí)了服務(wù)器well-know服務(wù)名、總線接口名稱、總線對(duì)象路徑、服務(wù)通信端口，同時(shí)還有會(huì)話時(shí)發(fā)送的指令名稱以及指令發(fā)送的周期。

1）實(shí)現(xiàn)網(wǎng)絡(luò)通信的流程：網(wǎng)絡(luò)通信接口的作用是實(shí)現(xiàn)服務(wù)動(dòng)態(tài)接入流程中各個(gè)節(jié)點(diǎn)之間的相互發(fā)現(xiàn)和指令的傳輸。需要首先開(kāi)啟底層socket通信功能，設(shè)置消息通道，接收和發(fā)送消息。然后創(chuàng)建AllJoyn會(huì)話服務(wù)器，步驟包括：創(chuàng)建總線接口對(duì)象，且允許從遠(yuǎn)程設(shè)備接收消息；生成總線接口對(duì)象，設(shè)置接口名稱和接口方法；注冊(cè)總線監(jiān)聽(tīng)器，用于監(jiān)聽(tīng)網(wǎng)絡(luò)中其他節(jié)點(diǎn)傳來(lái)的消息；激活總線附件對(duì)象；創(chuàng)建總線對(duì)象，用來(lái)實(shí)現(xiàn)接口中設(shè)置的方法；向總線接口對(duì)象中注冊(cè)總線對(duì)象；將總線附件連接到總線；向總線發(fā)布服務(wù)?？偩€監(jiān)聽(tīng)器對(duì)象用來(lái)監(jiān)聽(tīng)總線上的事件通知，即客戶端的加入、驗(yàn)證與退出。發(fā)布服務(wù)包括三個(gè)步驟：分別是請(qǐng)求服務(wù)、創(chuàng)建會(huì)話、發(fā)布服務(wù)名稱。創(chuàng)建會(huì)話時(shí)需要設(shè)置服務(wù)名稱并綁定總線監(jiān)聽(tīng)器。發(fā)布服務(wù)名稱時(shí)把通過(guò)唯一性驗(yàn)證的服務(wù)名稱發(fā)布到網(wǎng)絡(luò)中，供客戶端進(jìn)行發(fā)現(xiàn)。

2）建立會(huì)話的流程：會(huì)話模塊首先是監(jiān)聽(tīng)節(jié)點(diǎn)的接入狀態(tài)，狀態(tài)的監(jiān)聽(tīng)在代理總線對(duì)象中實(shí)現(xiàn)，有節(jié)點(diǎn)接入時(shí)，執(zhí)行函數(shù)，通過(guò)端口等節(jié)點(diǎn)配置信息，完成客戶端接入驗(yàn)證。驗(yàn)證完成后向節(jié)點(diǎn)發(fā)送指令，要求其發(fā)送服務(wù)描述信息。監(jiān)聽(tīng)接收的消息通過(guò)初始化服務(wù)器時(shí)注冊(cè)的消息控制器實(shí)現(xiàn)。當(dāng)接收到指令反饋時(shí)，將得到的信息進(jìn)行處理，加入到服務(wù)描述數(shù)據(jù)集中，并在系統(tǒng)狀態(tài)信息中標(biāo)識(shí)服務(wù)描述信息的變化。一旦發(fā)生節(jié)點(diǎn)離線，將該節(jié)點(diǎn)對(duì)應(yīng)的服務(wù)描述信息從數(shù)據(jù)庫(kù)中刪除，同時(shí)在系統(tǒng)參數(shù)數(shù)據(jù)集中標(biāo)識(shí)服務(wù)描述信息的變化。

1.2.3身份認(rèn)證協(xié)議設(shè)計(jì)

圖5 用戶加入安全組

如圖5為安全組授權(quán)者基于本組LivingRoomUUID使用安全管理器為已給定組ID的新用戶B生成成員證書過(guò)程，其中A接收的用戶B身份證書將直接保存到TEE環(huán)境中并加入TA的UUID生成成員證書。

1.3 數(shù)據(jù)加解密模塊設(shè)計(jì)

數(shù)據(jù)加密的過(guò)程就是REE與TEE環(huán)境間交互的過(guò)程，首先它需要通過(guò)客戶端API的封裝，然后根據(jù)數(shù)據(jù)結(jié)構(gòu)的命令字段通過(guò)TEE API調(diào)用相應(yīng)函數(shù)進(jìn)行運(yùn)算，并將執(zhí)行狀態(tài)和運(yùn)算結(jié)果通過(guò)共享內(nèi)存返回給客戶端應(yīng)用程序。

數(shù)據(jù)加密RA首先使用REE API進(jìn)行上下文環(huán)境初始化，經(jīng)過(guò)初始化之后可信服務(wù)才會(huì)被喚醒。RA通過(guò)調(diào)用TEEC_OpenSession函數(shù)打開(kāi)一個(gè)會(huì)話，用于連接TA使用安全服務(wù)，此時(shí)TEE內(nèi)開(kāi)始創(chuàng)建安全服務(wù)進(jìn)程。安全服務(wù)進(jìn)程創(chuàng)建完成后，運(yùn)行環(huán)境將會(huì)被切換到REE，可以打開(kāi)會(huì)話的句柄也會(huì)交回。REE接收返回結(jié)果并查看句柄是否有效，若失敗則結(jié)束通信，若成功則開(kāi)始準(zhǔn)備調(diào)用安全服務(wù)（此處特指AES加密算法），例如分配共享內(nèi)存。內(nèi)存分配成功后就可以調(diào)用TEEC_InvokeCommand函數(shù)向TA發(fā)送指令了。TA通過(guò)TA_InvokeCommandEntryPoint函數(shù)使用加密服務(wù)，并在命令執(zhí)行結(jié)束后將結(jié)果通過(guò)共享內(nèi)存返回給加密RA。當(dāng)數(shù)據(jù)量大時(shí)，此通信過(guò)程可以進(jìn)行多次，直到所有命令執(zhí)行過(guò)程都結(jié)束后將關(guān)閉會(huì)話、釋放內(nèi)存、關(guān)閉可信連接，過(guò)程如圖6所示：

圖6 數(shù)據(jù)加密處理流程

2 方案實(shí)現(xiàn)

本節(jié)通過(guò)設(shè)計(jì)案例對(duì)系統(tǒng)進(jìn)行可行性測(cè)試，部署中包括三個(gè)對(duì)等節(jié)點(diǎn)，均是由QEMU模擬器在PC上模擬出來(lái)并搭載Android系統(tǒng)。節(jié)點(diǎn)間通過(guò)局域網(wǎng)相連接。系統(tǒng)網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)如圖7所示。

2.1 用戶安全管理模塊的實(shí)現(xiàn)

本文中使用了三個(gè)連入同一網(wǎng)段的模擬終端，終端之間通過(guò)WIFI相連。首先搭建AllJoyn通信框架，并在終端上構(gòu)建OP-TEE項(xiàng)目使之成為具有可信執(zhí)行環(huán)境的終端。

為可信對(duì)等通信定義的唯一UUID標(biāo)識(shí)如圖8，通過(guò)該標(biāo)識(shí)來(lái)識(shí)別TEE服務(wù)。

圖7 系統(tǒng)結(jié)構(gòu)圖

圖8 使用TEE生成證書操作成功截圖

如圖8所示，調(diào)試信息表示監(jiān)視器成功進(jìn)行環(huán)境切換并生成cert。

通過(guò)帶參命令“-j（s） mychannel”執(zhí)行節(jié)點(diǎn)間通信，測(cè)試結(jié)果如圖9，圖10所示。

圖9 服務(wù)端運(yùn)行結(jié)果展示圖

圖10 消費(fèi)端B（C）運(yùn)行結(jié)果展示圖

兩個(gè)消費(fèi)端用戶成功接收到用戶A發(fā)送的文件消息，說(shuō)明會(huì)話組成功完成對(duì)新可信終端的驗(yàn)證，用戶B成功加入當(dāng)前會(huì)話組。節(jié)點(diǎn)A作為服務(wù)端創(chuàng)建會(huì)話并等待其他通信節(jié)點(diǎn)加入形成會(huì)話組，消費(fèi)端B和C經(jīng)過(guò)AllJoyn組內(nèi)已有節(jié)點(diǎn)安全認(rèn)證后成功加入該會(huì)話組，并可以使用服務(wù)端提供的服務(wù)，在本例中，服務(wù)端向其他節(jié)點(diǎn)共享一個(gè)已加密的保存著一串字母的文件，消費(fèi)端接收文件后通過(guò)節(jié)點(diǎn)間事先協(xié)商好的TEE內(nèi)部解密密鑰進(jìn)行文件的解密，最終呈獻(xiàn)給消費(fèi)端用戶的是明文。

2.2 數(shù)據(jù)加解密模塊的實(shí)現(xiàn)

為了直觀地表示出TEE可信服務(wù)對(duì)信息的處理結(jié)果，我們選擇了將經(jīng)過(guò)加密后的密文結(jié)果輸出到文件，如圖14所示。當(dāng)一次加密任務(wù)執(zhí)行結(jié)束后，當(dāng)前所在目錄下‘out’文件夾的出現(xiàn)證明了此次設(shè)備成功進(jìn)行了REE和TEE環(huán)境間通信，其中文本文件‘crypt’為被RA調(diào)用的TEE內(nèi)部安全服務(wù)執(zhí)行后通過(guò)共享內(nèi)存返回給REE的數(shù)據(jù)加密后的密文保存到本地的結(jié)果展示。同理，對(duì)密文執(zhí)行解密模塊實(shí)例化的輸出結(jié)果與加密結(jié)果有不同的只是輸出的文本文件為經(jīng)過(guò)解密后的明文。

圖11 TEE數(shù)據(jù)處理結(jié)果展示圖

2.3 模型安全性分析

上文中數(shù)據(jù)傳輸?shù)陌踩ǖ兰饶鼙ＷC獲取終端REE環(huán)境中密鑰過(guò)程的安全性，又能保證數(shù)據(jù)在向TEE傳輸?shù)倪^(guò)程中不被隱藏惡意程序截獲，另外，TrustZone的隔離特性保證了REE環(huán)境中除指定的加密程序外其他應(yīng)用程序無(wú)法獲得TEE的安全會(huì)話授權(quán)，在沒(méi)有獲得正確的加密服務(wù)命令標(biāo)識(shí)的前提下加密服務(wù)也不會(huì)執(zhí)行，從而保證了數(shù)據(jù)加解密過(guò)程的安全性。即使敵手攻破了終端的REE也無(wú)法通過(guò)窺探TEE可信服務(wù)的接口獲取有價(jià)值的信息，因?yàn)榱魅隦EE的敏感數(shù)據(jù)都是已經(jīng)過(guò)TEE加密或封裝的。假設(shè)數(shù)據(jù)在AllJoyn通信的過(guò)程中被敵手截獲，敵手無(wú)法拿到位于TEE環(huán)境中的加密密鑰也無(wú)法破解數(shù)據(jù)信息。

由上一段安全分析可知，敵手無(wú)法通過(guò)攻擊本方案獲取終端認(rèn)證密鑰，也無(wú)法破解AllJoyn通信中的認(rèn)證會(huì)話密鑰包，即終端不可偽造；即使敵手使用一個(gè)合法的移動(dòng)設(shè)備，在沒(méi)有獲得用戶的用戶名和口令的情況下，敵手也無(wú)法偽造自己的合法身份并使用可信功能和對(duì)等網(wǎng)絡(luò)介入與其他終端用戶的數(shù)據(jù)通信。

3 結(jié)束語(yǔ)

本文對(duì)可信對(duì)等通信系統(tǒng)需求進(jìn)行了分析，在研究了P2P網(wǎng)絡(luò)AllJoyn身份認(rèn)證、會(huì)話機(jī)制、對(duì)等機(jī)信息和解析協(xié)議、服務(wù)動(dòng)態(tài)接入、安全管理、TrustZone硬件隔離、GlobalPlatform軟件架構(gòu)等相關(guān)技術(shù)的基礎(chǔ)上，通過(guò)將TEE的數(shù)據(jù)存儲(chǔ)和處理模塊的功能與AllJoyn的對(duì)等機(jī)發(fā)現(xiàn)技術(shù)、身份認(rèn)證、會(huì)話綁定、對(duì)等機(jī)信息和解析相關(guān)協(xié)議相結(jié)合，設(shè)計(jì)了一個(gè)基于AllJoyn的可信對(duì)等通信系統(tǒng)，將AllJoyn的用戶認(rèn)證過(guò)程中密鑰與計(jì)算過(guò)程轉(zhuǎn)入具有高隔離性的TEE中保存執(zhí)行，之后，對(duì)實(shí)驗(yàn)結(jié)果的正確性進(jìn)行了驗(yàn)證并對(duì)方案的安全性進(jìn)行了分析，完成了對(duì)方案可行性的驗(yàn)證。

本方案僅對(duì)P2P中可信終端認(rèn)證部分做了改進(jìn)和驗(yàn)證，如何設(shè)計(jì)針對(duì)TEE終端的身份認(rèn)證算法有待進(jìn)一步研究。

[1]劉悅，李強(qiáng)，李舟軍. P2P網(wǎng)絡(luò)安全及防御技術(shù)研究綜述[J]. 計(jì)算機(jī)科學(xué)，2013（04）：9-13.

[2]白哲哲. 基于P2P的跨平臺(tái)即時(shí)通信軟件的設(shè)計(jì)與實(shí)現(xiàn)[D]. 電子科技大學(xué)，2014.

[3]楊波，馮登國(guó)，秦宇，等. 基于TrustZone的可信移動(dòng)終端云服務(wù)安全接入方案[J]. 軟件學(xué)報(bào)，2016，27（006）：1366-1383.

[4]鄭顯義，李文，孟丹. TrustZone技術(shù)的分析與研究[J]. 計(jì)算機(jī)學(xué)報(bào)，2016（7）：1912-1928.

[5]楊霞，劉志偉，雷航. 基于TrustZone的指紋識(shí)別安全技術(shù)研究與實(shí)現(xiàn)[J]. 計(jì)算機(jī)科學(xué)，2016（7）：147-152.

[6]巫岱玥，李強(qiáng)，余祥，等. 基于區(qū)塊鏈的對(duì)等網(wǎng)絡(luò)信任模型[J]. 計(jì)算機(jī)科學(xué)，2019，046（012）：138-147.

[7]孫海泳，楊霞，雷航，等.基于TrustZone的TEE設(shè)計(jì)與信息流形式化驗(yàn)證[J].電子科技大學(xué)學(xué)報(bào)，2019，48（02）：259-263.

[8]楊保絢，董攀，張利軍，等.基于TrustZone的安全應(yīng)用性能優(yōu)化[J].計(jì)算機(jī)工程與科學(xué)，2020，42（12）：2141-2150.

[9]Clarke I.，Sandberg O.，Wiley B.，et al. Freenet：a distributed anonymous information storage and retrieval system. In：Proc. of the International Workshop on Designing Privacy Enhancing Technologies：Design Issues in Annoymity and Unobservability，Springer-Verlag，New York，USA， 2001.46-66.

[10]Gummadi P.，Saroiu S.，Gribble S.. A measurement study of Napster and Gnutella as examples of peer-to-peer file sharing systems. ACM SIGCOMM Computer Communication Review， 2002，32（1）：82-82.

[11]http://en.wikipedia.org/wiki/BitTorrent#Throttling_and_encryption.

[12]Ripeanu M.，Iamnitchi A.，and Foster I.，Mapping the gnutella network，IEEE Internet Computing，6（1），2002.50-57.

[13]Leibowitz N.，Ripeanu M.，and Wierzbicki A.， Deconstructing the kazaa network，Proc.3th IEEE Workshop on Internet Applications. WIAPP 2003. San Jose，CA. USA.，IEEE， 2003.112-120.

[14]ARM. Building a Secure System using TrustZone Technology[M]. 2009.

[15]Global Platform Device Technology TEE Client APISpecification Version 1.0[EB/OL].2010. http://www.trustedcomputinggroup.org.

[16]Global Platform Device Technology TEE Internal API Specification Version 1.0[EB/OL].2011. http://www.trustedcomputinggroup.org.

[17]Samuel AB，Don F，Virginie G，F(xiàn)ranz H，Janne H，Milas F. The trusted execution environment：Delivering enhanced security at a lower cost to the mobile market. White Paper，Global Platform，2011.

[18]Trusted Computing Group. TPM MOBILE with trusted execution environment for comprehensive mobile device security. White Paper，Trusted Computing Group，Incorporated，2012. http://www.trustedcomputinggroup.org.

[19]Atul V. Get into the zone：Building secure systems with ARM TrustZone technology. White Paper，Texas Instruments，2013.

[20]Samsung. An overview of Samsung KNOX. White Paper，Samsung Electronics Co.，Ltd，2013.

[21]Nordstr?m E，Rohner C，Gunningberg P. Haggle：Opportunistic mobile content sharing using search[J]. ComputerCommunications，2014：121-132.

[22]http://www.peerdevicenet.net/index.html.

[23]Brian Spencer. Making It Easy for Devices to Connect-The All Joyn Peer-to-Peer Architecture [EB/OL].（2011-09-08）.https://developer.qualcomm.com/blog/making-it-easy-devices-connect-%E2%80%93-alljoyn-peer-peer-architecture.

[24]Santos N，Raj H，Saroiu S，Wolman A. Using ARM TrustZone to build a trusted language runtime for mobileapplications[J]. ACM Sigplan Notices，2014，49（1）：67-80.

[25]Yang B，F(xiàn)eng DG，Qin Y. A lightweight anonymous mobile shopping scheme based on DAA for trusted mobileplatform. IEEE，2014.9-17.

[26]GlobalPlatform Inc. GlobalPlatform Device Technology TEE System Architecture Version 1.1[EB/OL]. White Paper，2014.

[27]A Merlo，L Lorrai，L Verderame. Efficient trusted host-based card emulation on TEE-enabled Android devices[J].IEEE，2016：454-459.