具有可信約束的分布式存儲因果一致性模型

田俊峰，張俊濤，王彥骉

（1.河北大學(xué)網(wǎng)絡(luò)空間安全與計算機學(xué)院，河北 保定 071002；2.河北省高可信信息系統(tǒng)重點實驗室，河北 保定 071002）

1 引言

隨著互聯(lián)網(wǎng)信息時代的高速發(fā)展，用戶需求也變得多樣化，具有高性能和可擴展性等優(yōu)點的分布式云存儲解決了這一困局。為了提供高速、可靠并且成本低的分布式存儲服務(wù)，云服務(wù)提供商一般將服務(wù)器節(jié)點分布在不同的地理位置[1]。數(shù)據(jù)一致性是分布式云存儲中的基本問題之一。在分布式系統(tǒng)中對各個節(jié)點間的數(shù)據(jù)進行同步，保持一致的狀態(tài)即為數(shù)據(jù)一致性。

數(shù)據(jù)一致性按照強度大小可分為最終一致性、因果一致性與嚴(yán)格一致性。最終一致性的強度最弱，例如亞馬遜的Dynamo[2]存儲平臺。嚴(yán)格一致性是一種強一致性，指的是每個節(jié)點中的更新都在其他節(jié)點中立即可見[3]，對分布式系統(tǒng)的性能有極高的要求。因果一致性屬于中間強度的數(shù)據(jù)一致性，只需使每個節(jié)點中更新事件之間的因果順序?qū)ζ渌?jié)點可見。因果一致性模型不僅能為用戶提供數(shù)據(jù)的及時更新，也能在因果依賴型的影響可見時為用戶事件提供因果序保障。

隨著信息技術(shù)的高速發(fā)展，現(xiàn)有的弱數(shù)據(jù)一致性平臺越來越難以滿足多樣化的用戶需求。強度更高、性能更好的因果一致性成為眾多學(xué)者的研究對象。Didona 等[4]提出的Okapi 是一種使用了混合邏輯時鐘（HLC,hybrid logical clock）[5]和全局穩(wěn)定向量（GSV,global stable vector）的因果一致性方案。該方案通過一個GSV 來追蹤當(dāng)前分區(qū)最新條目的時間戳，并規(guī)定當(dāng)所有節(jié)點都將更新信息同步完成后才允許用戶查詢，這導(dǎo)致其更新可見性時延很高。Roohitavaf 等[6]提出了一種使用HLC 和數(shù)據(jù)中心穩(wěn)定向量的因果一致性模型CausalSpartan。該模型提出了全新的分區(qū)穩(wěn)定向量，降低了更新可見性時延。但該模型是在理想情況下實現(xiàn)的，并未提出對第三方篡改等風(fēng)險的應(yīng)對策略。Bravo 等[7]提出的Saturn 方案依靠元數(shù)據(jù)序列化標(biāo)簽來傳遞元數(shù)據(jù)的因果序，數(shù)據(jù)副本據(jù)此對元數(shù)據(jù)的因果一致性約束進行校驗。此外，Saturn 還通過一組序列化器在彼此接近的2 個數(shù)據(jù)中心之間快速地建立起元路徑，加快標(biāo)簽在拓撲網(wǎng)絡(luò)中的傳播速度。該方案很好地解決了吞吐量和更新可見性時延之間的權(quán)衡問題，也能充分利用部分地理復(fù)制策略的優(yōu)勢。但序列化器運行在客戶端的關(guān)鍵路徑上，影響了系統(tǒng)的并發(fā)性，同時，該方案也并未考慮可能遇到的數(shù)據(jù)安全性問題。

隨著云存儲的不斷普及與應(yīng)用，安全問題已成為制約其進一步發(fā)展的重要因素[8]。分布式的系統(tǒng)部署、開放的網(wǎng)絡(luò)環(huán)境、復(fù)雜的數(shù)據(jù)應(yīng)用和眾多的用戶訪問，都使大數(shù)據(jù)在機密性、完整性、可用性等方面面臨更大的挑戰(zhàn)。服務(wù)的高可用性是用戶最關(guān)心的，為了提高系統(tǒng)的容災(zāi)能力，應(yīng)對節(jié)點失敗的情況，云服務(wù)平臺往往會創(chuàng)建冗余資源。冗余數(shù)據(jù)在提高服務(wù)可用性的同時，擴大了數(shù)據(jù)的信任域，帶來了一定的安全風(fēng)險，需要云平臺在用戶訪問控制以及數(shù)據(jù)存儲過程的安全性方面付出更高的成本[9]，勢必會對系統(tǒng)性能造成一定的影響。數(shù)據(jù)完整性避免了未經(jīng)授權(quán)的用戶訪問數(shù)據(jù)，從而對數(shù)據(jù)進行篡改或其他非法操作[10]。身份認證能為用戶和云服務(wù)提供商的身份真實性提供保證[11]，所以要在用戶連接、訪問和使用數(shù)據(jù)的過程中對用戶的身份進行驗證和確認[12]。針對現(xiàn)有基于公鑰基礎(chǔ)設(shè)施（PKI,public key infrastructure）的跨域身份認證機制存在信任路徑長、證書驗證效率低、域間信任路徑構(gòu)建復(fù)雜等問題，楊小東等[11]利用代理重簽名技術(shù)提出了一種云環(huán)境下的跨域身份認證方案。可信計算是一種信息系統(tǒng)安全新技術(shù)，沈昌祥等[13]提出了以芯片為信任根、主板為平臺、軟件為核心、網(wǎng)絡(luò)為紐帶的應(yīng)用成體系的可信計算體系框架。何欣楓等[14]對可信云平臺的構(gòu)建與可信虛擬化技術(shù)進行了詳細的分類與介紹。劉川意等[15]提出了一種將虛擬可信平臺模塊（vTPM,virtual trusted platform module）和可信審計技術(shù)結(jié)合起來的用戶可信運行環(huán)境構(gòu)建與審計機制。田俊峰等[16]基于可信平臺模塊（TPM,trusted platform module）提出了基于TPA 云聯(lián)盟的數(shù)據(jù)完整性驗證模型，改進了傳統(tǒng)單節(jié)點TPM 性能較低的缺點。

目前的數(shù)據(jù)因果一致性方案集中討論基于拜占庭容錯的建模方法對數(shù)據(jù)復(fù)制過程進行改進，旨在降低用戶數(shù)據(jù)同步時間等方面性能，而這些因果一致性平臺都是建立在理想環(huán)境下的，并未考慮實際云存儲環(huán)境下的節(jié)點可信問題。現(xiàn)有的可信云平臺節(jié)點管理、可信云平臺節(jié)點可信認證等研究方案中鮮有支持數(shù)據(jù)一致性的相關(guān)方案。Roohitavaf 等[17]提出了一種分布式鍵值框架（DKVF,distributed key-value framework），并且集成了性能測試與底層數(shù)據(jù)存儲接口，但并未考慮分布式存儲環(huán)境中的安全風(fēng)險，不能提供安全約束下的節(jié)點管理方案。

目前，數(shù)據(jù)一致性方面的研究都是基于理想環(huán)境的，并未考慮網(wǎng)絡(luò)環(huán)境中的不安全因素[18]，原因在于若針對所有的元數(shù)據(jù)提供安全認證和完整性校驗，勢必會造成極大的性能開銷。但現(xiàn)今網(wǎng)絡(luò)中的安全風(fēng)險已是不可忽略的熱點問題，為了準(zhǔn)確并高效地在實際云存儲環(huán)境中進行身份認證、一致性元數(shù)據(jù)的完整性校驗，保證數(shù)據(jù)因果一致性，本文在混合邏輯時鐘和HashGraph 的基礎(chǔ)上，結(jié)合現(xiàn)有的可信云平臺相關(guān)成果，提出了具有可信約束的分布式存儲因果一致性模型（CCT,causal consistency model with trusted constraint）。本文的主要工作如下。

1) 客戶端操作中，客戶端將客戶端可信簽名（TSc,trusted signature of client）隨相應(yīng)的請求信息一起發(fā)送給服務(wù)端。當(dāng)收到服務(wù)端返回的消息后，客戶端首先對其中的服務(wù)端可信簽名（TSs,trusted signature of service）進行驗證，若驗證成功，則依據(jù)響應(yīng)消息更新本地依賴集。最后借鑒HashGraph共識機制對收到的數(shù)據(jù)可信證據(jù)（TPS,trusted proof of data series）在本地進行驗證。

2) 服務(wù)端操作中，在收到客戶端請求后，服務(wù)端對TSc 進行驗證，若結(jié)果為不可信，則拒絕處理該請求。若驗證為可信狀態(tài)，則將響應(yīng)結(jié)果與對應(yīng)的TSs 一起發(fā)送到客戶端。節(jié)點內(nèi)部、節(jié)點間同步數(shù)據(jù)的過程中，將TSs 作為節(jié)點穩(wěn)定狀態(tài)向量的一部分內(nèi)容進行同步，從而為數(shù)據(jù)因果一致性協(xié)議提供最大程度的可信保障。

3) 采用部分地理復(fù)制策略，即當(dāng)前數(shù)據(jù)中心只存儲完整數(shù)據(jù)集的任意子集[19]，借鑒區(qū)塊鏈技術(shù)HashGraph 中的共識機制，各個節(jié)點使用混合邏輯時鐘隨機地向其他節(jié)點同步最新的記錄與可信狀態(tài)。每個節(jié)點的可信狀態(tài)具有一定期限，節(jié)點內(nèi)部的分區(qū)共享當(dāng)前節(jié)點的可信狀態(tài)。

2 背景知識

2.1 可信云平臺

云計算的可信問題是云服務(wù)廣泛推廣面臨的一個關(guān)鍵問題。構(gòu)建可信云平臺是保障云計算安全的基礎(chǔ)之一。可信云平臺利用底層的TPM 作為可信任根，構(gòu)建可信任鏈，通過平臺進行驗證，保證節(jié)點處于安全可信狀態(tài)[15]?？尚旁破脚_的核心之一是可信虛擬化?？尚旁破脚_通過vTPM 模擬硬件TPM 的功能，實現(xiàn)不同虛擬機對硬件TPM 的共享，同時保證了虛擬機之間的相對獨立，提高了安全性。目前，我國已經(jīng)構(gòu)建起相對完整的可行計算體系，并提出了可信密碼模塊（TCM,trusted cryptography module）標(biāo)準(zhǔn)[14]。

可信云平臺基于TPM 技術(shù)，提供安全內(nèi)存的讀寫TSS_Pcr()、非易失性（NV,non-volatile）存儲的安全認證 TSS_Quote()以及安全信息的認證TSS_Sig()等安全機制。其中TSS_Pcr() 和TSS_Quote()可為當(dāng)前云存儲環(huán)境提供可信認證，包含存儲狀態(tài)、服務(wù)端口以及通信地址等內(nèi)容，確保了客戶端及服務(wù)端身份的真實性。實際分布式存儲環(huán)境中，在云服務(wù)商為用戶提供元數(shù)據(jù)的查詢、讀取等服務(wù)的過程中還存在數(shù)據(jù)被篡改的安全隱患。針對此風(fēng)險提出的可信云平臺技術(shù)基于TPM 提供的可信度量機制，使用安全信息的認證機制TSS_Sig()可為同步后的數(shù)據(jù)提供完整性簽名，使客戶端在收到服務(wù)端響應(yīng)后對數(shù)據(jù)進行完整性驗證，解決了非安全環(huán)境中數(shù)據(jù)完整性驗證的問題。

可信云平臺的可信認證與數(shù)據(jù)加密機制在最大程度上保障了實際環(huán)境中用戶身份與數(shù)據(jù)的可信度。但由于其節(jié)點動態(tài)管理的性能瓶頸與可信證據(jù)難以統(tǒng)一認證等問題，在實際分布式存儲環(huán)境中TPM 極難普遍采用。田俊峰等[20]提出的可信云聯(lián)盟方案是一種可信云平臺管理模型。該模型在TPM 的基礎(chǔ)上設(shè)計了數(shù)據(jù)保護與可信認證、可信證據(jù)度量等組件，并包含vTPM，提供了安全存儲、可信度量等接口。該云聯(lián)盟技術(shù)解決了不同位置TPM 之間的信任問題，即在TPM 的基礎(chǔ)上設(shè)置信任根（rTPM,root TPM），將可信證據(jù)的統(tǒng)一度量問題簡化為rTPM 之間對可信證據(jù)的傳遞。

2.2 因果一致性原理

數(shù)據(jù)一致性一般指在分布式存儲中，位于不同地理位置的用戶讀取到的數(shù)據(jù)保持一致。因果一致性作為一種中間強度的一致性，是目前數(shù)據(jù)一致性的重要方案之一。相比于最終一致性難以及時更新數(shù)據(jù)的缺點和嚴(yán)格一致性對性能開銷的高要求，因果一致性在保證數(shù)據(jù)能及時同步的前提下，為用戶提供保障因果序的存儲服務(wù)。

因果一致性是基于用戶操作之間的前后關(guān)系定義的，該關(guān)系的定義如下。

定義1用戶操作的前后關(guān)系。a和b定義為2 個操作，當(dāng)且僅當(dāng)至少以下條件之一成立時，a在b之前發(fā)生成立。

1)a、b在同一線程中執(zhí)行，并且a在b之前提交。

2)a和b在不同線程中執(zhí)行，a是PUT(k,v)操作，b是GET(k)操作，b返回由a寫入的值。

3) 存在操作c，使a→c并且c→b成立。

a與b之間的這種關(guān)系可表示為a→b，也稱為a因果依賴于b。

定義2因果關(guān)系。如果用X和Y分別表示鍵x和y的值，若PUT(x,X)→PUT(y,Y)成立，則X與Y為因果關(guān)系，可表示為XdepY。

定義3可見性。如果客戶端c的GET(k)操作結(jié)果為v'，并且v'滿足v'=v或者┐(vdepv')，那么鍵k的值v對客戶端c是滿足可見性的。

定義4因果一致性。假設(shè)數(shù)據(jù)中心中存在2 個任意的鍵x和y，X為鍵x的值，Y為鍵y的值，在XdepY的情況下，如果X、Y對客戶端c可見，那么該數(shù)據(jù)中心滿足“因果一致性”。

在實際云環(huán)境中，不同地理位置的節(jié)點中的數(shù)據(jù)存儲方案一般分為2 種，一種為完全地理復(fù)制，即分布式系統(tǒng)中每個數(shù)據(jù)中心都存儲完整的數(shù)據(jù)集；另一種為部分地理復(fù)制，即當(dāng)前數(shù)據(jù)中心只存儲完整數(shù)據(jù)集的任意子集。

本文提出的CCT 模型使用部分地理復(fù)制方案，基于可信機制為用戶的因果一致性元數(shù)據(jù)提供可信約束，用戶在當(dāng)前節(jié)點寫入數(shù)據(jù)之后，當(dāng)前的更新狀態(tài)也會與其余節(jié)點進行同步，同步過程中除了可信證據(jù)的傳遞，還包括節(jié)點穩(wěn)定狀態(tài)同步與時鐘同步。

2.3 HashGraph

區(qū)塊鏈?zhǔn)且环N非常優(yōu)秀的分布式數(shù)據(jù)存儲技術(shù)，包含2 種核心思想：分布式賬本存儲與共識機制，解決了分布式節(jié)點中交易的信任和安全問題，可實現(xiàn)更廣泛意義上的安全多方計算[21]。HashGraph 是區(qū)塊鏈的一種改進方案，提供分布式賬本和共識機制的數(shù)據(jù)存儲，主要采用八卦同步和虛擬投票的方式對新產(chǎn)生的交易進行存儲和同步。

在HashGraph 中，共識機制是通過不同事件間的八卦同步實現(xiàn)的。如圖1 所示，用戶A將發(fā)生的事件隨機與相鄰的其余用戶進行交流，將其所有的事件歷史告訴用戶B。同樣B也執(zhí)行相同操作，其余成員也是如此。這樣，如果環(huán)境中產(chǎn)生一個新的事件，該信息會以指數(shù)級的速度在整個環(huán)境中傳播，直到所有成員同步完成該事件。

圖1 相鄰事件之間的八卦同步

此外，用戶不僅會同步新發(fā)生的事件，還會確切地知道其他用戶什么時候同步了該事件。當(dāng)所有成員都有HashGraph 的副本時，即達成了最新狀態(tài)的共識。

當(dāng)所有節(jié)點都收到用戶A發(fā)生的事件后，當(dāng)前環(huán)境下記錄事件歷史的賬單就完成了同步。這是因為HashGraph 所有副本都同步完事件歷史后，任意副本（例如用戶D）都知道“其他所有副本都已同步此事件”，即形成了全網(wǎng)共識。HashGraph 最終達成的效果就是所有用戶并沒有聚到一起進行表決，也能公認當(dāng)前事件的完成，從而達成共識。

2.4 混合邏輯時鐘

傳統(tǒng)的因果一致性協(xié)議采用單調(diào)的物理時鐘作為判斷因果序的依據(jù)，例如GentleRain 模型[22]，在物理時鐘的基礎(chǔ)上定義了一個單向向量，即全局穩(wěn)定時間（GTS,global stable time）。該向量使用數(shù)據(jù)條目的更新時間戳作為判斷因果序的依據(jù)。若采用物理時鐘，各個節(jié)點間的時鐘無法在同一段時間內(nèi)完全達成一致，從而產(chǎn)生時鐘漂移，無法準(zhǔn)確判斷用戶事件的因果序。在實際應(yīng)用中，物理時鐘是單調(diào)遞增的，不能倒退。假設(shè)在一個由2 個數(shù)據(jù)中心A和B組成的系統(tǒng)中，2 個數(shù)據(jù)中心的GST 為5，這意味著2 個數(shù)據(jù)中心時間戳小于5 的所有值都能被用戶查詢到。假設(shè)數(shù)據(jù)中心A在時間戳為5 時更新了一條數(shù)據(jù)Item1，而此時數(shù)據(jù)中心B與數(shù)據(jù)中心A的時鐘存在偏差，向A同步一條時間戳為6 的數(shù)據(jù)Item2。由于該數(shù)據(jù)的時間戳高于GST，因此Item2不能被用戶查詢到，即該分布式系統(tǒng)無法為用戶提供準(zhǔn)確的因果一致性數(shù)據(jù)的讀寫服務(wù)。

邏輯時鐘僅對定義2 中的因果關(guān)系有要求，即只記錄客戶端發(fā)生事件的前后順序，與事件發(fā)生的具體物理時間不相關(guān)。

HLC 結(jié)合了邏輯時鐘和物理時鐘兩者的優(yōu)勢。事件E的HLC 時間戳表示為E.hlc，該時間戳是一個元組

算法1混合邏輯時鐘

輸入事件E，物理時間pt

輸出時間戳

算法1 是HLC 的計算過程，分別為客戶端產(chǎn)生事件時的時鐘定義方法與接收事件之后對2 個時間戳元素進行檢查的時鐘同步方法。若2 個事件m和n的l.E相同，但m在n之前發(fā)生，混合邏輯時鐘則將c.m設(shè)置為高于c.n的值，從而為事件m、n提供因果序判別依據(jù)。

3 具有可信約束的CCT 協(xié)議

本文提出的可信約束下的CCT 協(xié)議結(jié)合了可信云平臺中的可信認證機制，不僅對節(jié)點與客戶端的可信身份簽名TS 進行驗證，而且將節(jié)點可信證據(jù)的收集、管理與數(shù)據(jù)因果一致性協(xié)議相結(jié)合，為用戶一致性元數(shù)據(jù)的安全存儲與操作提供了保障。圖2 為CCT 模型的實體流程。

圖2 CCT 模型的實體流程

此外，CCT 協(xié)議借鑒HashGraph 共識機制，將用戶每次的存、取操作均看作一次事件，每次處理用戶的存、取請求之后都基于可信機制為該操作數(shù)據(jù)和依賴集分配一個TPS，作為事件歷史的簽名信息。分布式存儲副本在處理完用戶請求或在固定時間間隔內(nèi)未處理任何請求的情況下，均隨機與其連接的其他副本同步最新狀態(tài)，最后各副本之間未聚合在一起進行投票，但都快速地達成了最新狀態(tài)的共識。

CCT 協(xié)議中對因果一致性操作提供的可信機制不僅包括客戶端以及服務(wù)端的身份認證，還包括數(shù)據(jù)因果一致性元數(shù)據(jù)的完整性驗證，即服務(wù)端處理PUT、GET 請求后均計算元數(shù)據(jù)和更新后依賴集的數(shù)據(jù)可信證據(jù)并發(fā)送到客戶端，以驗證操作和結(jié)果的完整性和可信性。

分布式環(huán)境中，數(shù)據(jù)一致性協(xié)議僅靠服務(wù)端提供的可信機制，難以提供可信證據(jù)的傳遞驗證，進而無法保證整體分布式環(huán)境的可信狀態(tài)。基于可信認證的CCT 因果一致性協(xié)議中不僅包括了客戶端與服務(wù)端的身份認證與一致性數(shù)據(jù)完整性校驗機制，還對服務(wù)端之間的數(shù)據(jù)同步過程進行了安全約束。

CCT 協(xié)議中客戶端與服務(wù)端之間的寫入（PUT）操作和查詢（GET）操作的具體過程如圖3(a)和圖3(b)所示，相對應(yīng)的算法詳見算法2 和算法3。

圖3 CCT 協(xié)議中的PUT 和GET 操作

CCT 模型基于可信云平臺對客戶端與服務(wù)端之間的通信進行身份認證與因果一致性數(shù)據(jù)完整性校驗；同時對服務(wù)端之間的消息同步進行安全約束；通過使用HLC 與服務(wù)端部分穩(wěn)定向量（PDSV,part data stable vector），減少了客戶端與服務(wù)端之間的消息傳播的體量；同時借鑒HashGroup 共識機制的消息傳播方式，加快了消息同步速度。因此，CCT 模型在為數(shù)據(jù)因果一致性系統(tǒng)規(guī)避安全風(fēng)險的同時并沒有造成很高的性能開銷。相比于未考慮安全約束的因果一致性方案如 Okapi、CausalSpartan 等，CCT 模型在環(huán)境中存在不可信第三方時，可以為數(shù)據(jù)因果一致性操作提供安全保障，防止數(shù)據(jù)被篡改；與使用數(shù)據(jù)標(biāo)簽提供安全校驗的Saturn 模型相比，大大降低了更新可見性時延，提高了系統(tǒng)性能。

3.1 客戶端中的可信機制

算法2 是客戶端中的GET 操作和PUT 操作的算法。其中客戶端首次運行時先對自身運行環(huán)境、可信存儲空間做出認證，結(jié)合可信云平臺中的可信簽名機制，分配身份簽名TSc，作為服務(wù)端處理請求的依據(jù)。當(dāng)客戶端中存在不安全因素使可信存儲空間或運行環(huán)境存在風(fēng)險時，可信認證失敗，用戶可依據(jù)錯誤信息對客戶端進行檢查。

算法2客戶端c中的可信約束

GET 操作

輸入鍵k，DSVc，TSc

輸出值v，ds，PDSV，TSs，TPS

PUT 操作

輸入鍵k，值v，TSc，DSVc

輸出ut,m,TSs,TPS

在GET 過程中，若客戶端分配可信簽名成功，用戶將客戶端可信簽名TSc 與查詢請求一起向服務(wù)端發(fā)送。查詢請求中還包含了客戶端數(shù)據(jù)穩(wěn)定向量（DSVc,data stable vector of client），用來與節(jié)點同步最新狀態(tài)。客戶端收到服務(wù)端返回的響應(yīng)消息之后，先對服務(wù)端簽名TSs 進行驗證。驗證通過后，根據(jù)其中的服務(wù)端部分穩(wěn)定向量更新自身依賴關(guān)系集（DSc,dependency series client）。然后根據(jù)更新之后的依賴關(guān)系集計算數(shù)據(jù)可信證據(jù)，并與收到的服務(wù)端數(shù)據(jù)TPS 進行驗證。若驗證成功說明當(dāng)前操作來源為已連接且認證為可信的服務(wù)節(jié)點，且基于可信認證機制驗證的數(shù)據(jù)滿足可信約束下的完整性、數(shù)據(jù)因果一致性，否則返回錯誤信息，由客戶端排查錯誤并重新發(fā)起申請。

客戶端中的PUT 過程與GET 過程相似，客戶端將自身可信身份簽名TSc 封裝進PUT 請求消息發(fā)送給服務(wù)端?？蛻舳嗽谑盏椒?wù)端響應(yīng)后同樣首先結(jié)合TPM 2.0 可信認證機制校驗服務(wù)端的身份簽名TSs，然后根據(jù)響應(yīng)消息中為數(shù)據(jù)條目分配的存儲位置m以及時間戳ut 更新本地依賴關(guān)系集。最后計算依賴關(guān)系集的數(shù)據(jù)可信證據(jù)，與服務(wù)端發(fā)來的數(shù)據(jù)TPS 進行校驗，若校驗失敗則返回錯誤信息并且駁回該請求，進行重新認證與發(fā)送。

3.2 服務(wù)端中的可信機制

服務(wù)端操作一般處理過程包含GET、PUT 這2 個操作，GET 過程如算法3 所示。首先生成TSs。在處理客戶端GET 請求之前，集群對客戶端可信簽名TSc 進行校驗，若身份認證通過則依據(jù)客戶端穩(wěn)定狀態(tài)DSVc 更新副本的DSV。其次根據(jù)該查詢請求中的鍵在安全存儲中檢索對應(yīng)鍵的最新值并更新依賴關(guān)系集ds。再次計算k-v條目和依賴關(guān)系集的數(shù)據(jù)TPS。最后將查詢到的值v、依賴關(guān)系集ds、服務(wù)端部分穩(wěn)定向量PDSV、服務(wù)端可信簽名TSs 以及數(shù)據(jù)可信證據(jù)TPS 打包成為響應(yīng)消息發(fā)送到客戶端。因為客戶端與服務(wù)端運行環(huán)境中的可信約束是基于可信云聯(lián)盟技術(shù)的，所以無論是客戶端還是服務(wù)端，均可對收到的可信身份簽名、數(shù)據(jù)可信證據(jù)進行校驗。

算法3服務(wù)端中的GET 和PUT 操作

GET 操作

輸入鍵k，DSVc，TSc

輸出值v，ds，PDSV，TSs，TPS

PUT 操作

輸入鍵k，值v，DSVc，TSc

輸出ut，m，TSs，TPS

算法3 中還包含了服務(wù)端的PUT 操作過程。首先生成TSs 并對TSc 進行驗證，不僅能保障身份可信，更能對客戶端請求寫入數(shù)據(jù)進行安全認證。若客戶端身份滿足可信約束，則為該請求創(chuàng)建存儲空間，分配鍵值鏈空間，并更新本地穩(wěn)定狀態(tài)和依賴關(guān)系集ds。最后計算數(shù)據(jù)TPS 并將響應(yīng)消息發(fā)送到客戶端，其中內(nèi)容包括時間戳ut、分配的存儲空間m、依賴集數(shù)據(jù)可信證據(jù)TPS 和服務(wù)端身份可信簽名TSs。此外，服務(wù)端處理完客戶端的PUT 請求后還要與其余分區(qū)共享當(dāng)前最近寫入狀態(tài)，即向相鄰分區(qū)發(fā)送復(fù)制消息(Replicated)，參照 HLC、HashGraph 共識機制，由數(shù)據(jù)中心根分區(qū)隨機與其余數(shù)據(jù)中心同步最新狀態(tài)，詳見3.3 節(jié)。

3.3 服務(wù)端之間的同步機制

基于可信認證的CCT 因果一致性協(xié)議中包括了客戶端與服務(wù)端的可信認證過程，其中節(jié)點間同步的過程如圖4 所示。針對實際云環(huán)境中分布式數(shù)據(jù)的存取情況進行了調(diào)查與分析，其中用戶的存取請求大多集中在11:00—23:00，CCT 模型將服務(wù)運行周期設(shè)定為24 h，即在凌晨2 點為系統(tǒng)重新分配認證證據(jù)，在接下來的可信周期之內(nèi)節(jié)點與客戶端能夠在彼此可信的前提下，提供數(shù)據(jù)一致性元數(shù)據(jù)的存取操作。

圖4 為CCT 模型中針對節(jié)點間狀態(tài)進行更新的過程，其滿足因果一致性的可信約束體現(xiàn)在兩方面。一方面為不同地點之間的副本更新步驟中，基于可信云聯(lián)盟機制運行為每個副本設(shè)置了DSV 和TSs。其中DSV 不僅是判斷客戶端存取請求的時鐘狀態(tài)是否落后于當(dāng)前副本最新狀態(tài)的判斷依據(jù)，還是對副本之間最新狀態(tài)進行同步的依據(jù)。另一方面則為副本內(nèi)部的數(shù)據(jù)存儲分區(qū)在處理存取請求時，也基于樹形拓撲結(jié)構(gòu)與數(shù)據(jù)中心根分區(qū)共享彼此的分區(qū)可信穩(wěn)定分量（PV,partion vector），該分量的生成依據(jù)為副本的穩(wěn)定狀態(tài)，每次副本在分布式環(huán)境中與其副本同步穩(wěn)定狀態(tài)后均將最新條目時間戳和可信副本鏈擴散到內(nèi)部分區(qū)中，數(shù)據(jù)分區(qū)則以此為依據(jù)對自身存儲狀態(tài)進行更新。

圖4 CCT 模型中各數(shù)據(jù)中心間的同步

算法4服務(wù)端中的HEARTBEAT 消息

輸入無

輸出心跳消息

4 仿真實驗與結(jié)果分析

CCT 模型基于Berkeley DB 設(shè)計了底層數(shù)據(jù)存儲和檢索方式并通過Java 實現(xiàn)。本實驗在項目組開發(fā)的HBU-Cluster 平臺基礎(chǔ)上，將不同地點的集群副本在本地進行了模擬。HBU-Cluster 平臺是項目組開發(fā)的一個分布式鍵值存儲管理框架，使用Google 的Protocol Buffer 將數(shù)據(jù)因果一致性協(xié)議結(jié)構(gòu)化并集成Yahoo 的YCSB 基準(zhǔn)測試模塊作為性能測試工具。

HBU-Cluster 平臺還實現(xiàn)了 GentleRain 與CausalSpartan 協(xié)議，并提供了基準(zhǔn)測試結(jié)果。為了模擬實際分布式環(huán)境中不穩(wěn)定的用戶請求情況，實驗將測試負載均設(shè)置為共1 000 個操作，對不同模型處理不同并發(fā)請求的可信約束性能開銷進行了測試與統(tǒng)計。實驗基于具有自主知識產(chǎn)權(quán)的可信云平臺YF-I，規(guī)格如下：運行NeoKylin Linux Trusted OS V6(x64)，CPU*12:Intel Xeon E5-2603，1.6 GHz，16 GB 內(nèi)存，240 GB 存儲。

4.1 存在不可信節(jié)點的情況

CCT 模型中服務(wù)端對存儲節(jié)點的存儲狀態(tài)和運行機制進行了安全認證，項目組在CCT 模型的基礎(chǔ)上，為分布式存儲環(huán)境設(shè)置了5 個存儲副本，每個副本均分配一個分區(qū)，副本距離則在本地的可信云服務(wù)器中進行模擬，與本地的首節(jié)點位置的距離分別模擬為100 km、500 km、1 000 km、1 500 km，以期模擬實際云環(huán)境中云服務(wù)商將數(shù)據(jù)副本分布在不同區(qū)域的情況。其中為末節(jié)點手動分配身份可信簽名，供其余節(jié)點校驗身份簽名，在不干擾客戶端存取操作的前提下進行驗證與測試。

為了模擬不可信環(huán)境中的風(fēng)險，例如木馬等非法第三方對因果一致性數(shù)據(jù)依賴集進行篡改，本文實驗同時在末節(jié)點設(shè)置了不同比例的元數(shù)據(jù)條目修改與驗證機制，供HBU-Cluster 平臺對結(jié)果進行驗證與測試。為了使結(jié)果更清晰地展現(xiàn)，本節(jié)在客戶端模擬了不同并發(fā)請求的情況，例如低并發(fā)環(huán)境設(shè)置吞吐負載為5～10 個/s，同步心跳間隔為0.1 s；而高并發(fā)環(huán)境模擬條件降低副本同步心跳間隔為0.01 s，同時將吞吐負載增加至50～100 個/s。在處理完服務(wù)端PUT 操作后，將該條目對應(yīng)依賴集的隨機一個條目篡改為0～9 的隨機數(shù)。為了避免偶然性誤差，實驗結(jié)果均是3 次完成1 000 個存取操作的平均值，最后分別針對不同的篡改比例進行數(shù)據(jù)完整性校驗，結(jié)果如圖5 所示。

圖5 不同并發(fā)環(huán)境下模擬依賴集篡改后可信驗證的結(jié)果

圖5 結(jié)果顯示，在不可信節(jié)點對數(shù)據(jù)依賴集進行篡改后，5 個不同比例均全部驗證了對應(yīng)比例的數(shù)據(jù)風(fēng)險。針對實際云環(huán)境中數(shù)據(jù)篡改的風(fēng)險，CCT 模型針對25%以下的數(shù)據(jù)篡改風(fēng)險只返回風(fēng)險信息，超過該閾值后則拒絕提供一致性數(shù)據(jù)存取服務(wù)。圖5(a)結(jié)果中低負載情況下由于副本間同步更新間隔相對較長，即心跳間隔較大，造成數(shù)據(jù)依賴集模擬修改后，后續(xù)操作查詢結(jié)果中存在依賴集驗證失敗的情況，因此每個篡改比例的驗證結(jié)果均存在0.08%～1.09%的誤檢測率，平均誤檢測率為0.44%。

圖5(b)對實際存儲環(huán)境中普遍存在的高負載處理情況進行了模擬，除了降低副本同步心跳間隔和提高負載，其余條件并未進行改變，基于此條件在客戶端對隨機寫入的數(shù)據(jù)進行查詢同時進行驗證。結(jié)果顯示，相比于在低并發(fā)環(huán)境中，CCT 模型在高并發(fā)環(huán)境下有更好的性能表現(xiàn)，全部驗證出了不可信副本對一致性元數(shù)據(jù)的篡改，而誤檢測率范圍降低到了0.01%～0.32%。平均誤檢測率為0.094%，說明本節(jié)中CCT 模型在服務(wù)端設(shè)計可信約束的方案具有可行性。實驗中的高并發(fā)條件模擬了云服務(wù)提供商滿足不同用戶需求和應(yīng)對一些常見風(fēng)險的手段，即提升系統(tǒng)性能，在因果一致性服務(wù)處理過程中表現(xiàn)為更快的副本更新速度、更高的性能開銷，而CCT 在提升系統(tǒng)性能的基礎(chǔ)上相比低性能條件并未造成更高的開銷，且能提供更高效的一致性數(shù)據(jù)存取服務(wù)。

4.2 客戶端身份重新認證的情況

CCT 模型基于可信云聯(lián)盟技術(shù)為因果一致性服務(wù)提供了身份簽名和數(shù)據(jù)可信認證機制，但數(shù)據(jù)一致性存儲模型是針對客戶端請求提供服務(wù)的，不僅在服務(wù)端中提供了安全保障，對于客戶端中的身份簽名偽造、運行環(huán)境風(fēng)險也提出了安全約束。實驗基于HBU-Cluster 平臺在本地可信云服務(wù)器中部署了6 個數(shù)據(jù)副本，包含8 個分區(qū)，并在可信云聯(lián)盟技術(shù)基礎(chǔ)上分別設(shè)置5、30、200 個客戶端，每個測試結(jié)果均將分布式存儲集群運行2 天，可信周期設(shè)置為24 h，并將集群重啟時間設(shè)置在凌晨2 點。為了模擬實際云環(huán)境中社交應(yīng)用、Web 應(yīng)用存取NoSQL 型數(shù)據(jù)的條件，實驗將同步心跳機制設(shè)置為0.05 s，負載設(shè)置為50 個/s。

為了對CCT 模型中客戶端安全風(fēng)險的安全約束進行驗證與測試，實驗將客戶端中數(shù)據(jù)存取請求的發(fā)送方式設(shè)定為循環(huán)方式，并在11:00—23:00 進行客戶端單位吞吐量為100～500 個/s 的大量隨機存取，其余時間則為10～100 個/s?？蛻舳酥猩矸莺灻J證機制停止服務(wù)閾值為10%，即如果超過10%的客戶端請求可信驗證失敗，則對該客戶端進行報警處理并拒絕服務(wù)。實驗在停止服務(wù)閾值之下為客戶端請求隨機設(shè)計了2%、4%、6%、8%的身份偽造，對集群將客戶端偽造簽名重新認證的結(jié)果進行統(tǒng)計和分析，結(jié)果如圖6 所示。

圖6 不同客戶端數(shù)目環(huán)境中客戶端身份驗證表現(xiàn)

圖6 結(jié)果顯示，CCT 模型能將客戶端身份簽名偽造風(fēng)險完全識別，但由于通信環(huán)境的復(fù)雜性與可信云聯(lián)盟技術(shù)對可信證據(jù)的驗證性能缺陷，造成模型中依然存在一定的誤檢率。圖6(a)為使用5 個客戶端以循環(huán)方式向服務(wù)端發(fā)送PUT、GET 請求并驗證簽名、統(tǒng)計的結(jié)果。在為低數(shù)量級客戶端提供因果一致性數(shù)據(jù)存取服務(wù)時，CCT 模型有著較好的表現(xiàn)，其平均誤檢率為0.015%。圖6(b)將客戶端數(shù)量增加了5 倍，在同樣條件下進行測試的結(jié)果略差于圖6(a)中結(jié)果，其平均誤檢測率為0.05%。圖6(c)為模擬實際環(huán)境中較高客戶端請求的情況，客戶端規(guī)模為200 個，其余條件不變的情況下對身份篡改的驗證比例進行統(tǒng)計，平均誤檢率為0.155%。

實驗基于可信云平臺中的可信機制，對CCT模型中客戶端一方的可信約束進行了仿真測試，相比于CausalSpartan、Okapi 等未提供安全約束的傳統(tǒng)因果一致性方案，實驗結(jié)果證明了CCT 模型中提出的可信約束能對客戶端中身份簽名偽造、非法第三方等安全風(fēng)險進行識別并驗證，同時證明CCT模型在客戶端提出可信約束的方案是可行的。雖然局限于現(xiàn)有實際通信環(huán)境的復(fù)雜性和可信云平臺技術(shù)的性能瓶頸，仿真實驗結(jié)果存在一定的誤檢率，隨著客戶端連接數(shù)、處理用戶請求的并發(fā)量的提高，CCT 模型平均誤檢測率的遞增趨勢是比較穩(wěn)定的。安全約束的設(shè)計難免帶來一定的性能開銷，CCT 模型中由于提供安全約束帶來的PUT 時延、更新可見性時延相關(guān)分析在4.3 節(jié)進行了討論。

4.3 可信約束造成的性能開銷

可信云平臺在可信芯片TPM2.0 的基礎(chǔ)上提供安全策略管理、數(shù)據(jù)認證以及非對稱秘鑰協(xié)商等安全機制，在服務(wù)啟動、運行過程中均對身份認證、數(shù)據(jù)加密有著高標(biāo)準(zhǔn)的約束?；诳尚旁坡?lián)盟技術(shù)的CCT 模型提出了可信身份簽名、數(shù)據(jù)可信證據(jù)等安全約束，并將性能開銷控制在了較小的程度。本節(jié)參考文獻[6]中實驗環(huán)境（Intel Xeon E5-2680、3.75 GB 內(nèi)存并運行Ubuntu 14.04）和文獻[7]中實驗環(huán)境（Intel Xeon E5-2680、8 GB 內(nèi)存并運行Ubuntu 12.04），基于HBU-Cluster 平臺將實驗環(huán)境進行了設(shè)計和復(fù)現(xiàn)，最終針對CCT 模型中PUT 時延和更新可見性時延進行了分析，并與不包含安全約束的方案如GentleRain 和CausalSpartan，以及使用序列化標(biāo)簽進行因果一致性安全校驗的方案Saturn 進行了對比。

實驗在本地可信服務(wù)器部署了7 個副本，共包含7 個分區(qū)，副本同步心跳間隔為0.05 s，客戶端規(guī)模為2 個，客戶端單位負載設(shè)置為50 個/s。其中模擬FaceBook 數(shù)據(jù)集，將隨機鍵值大小設(shè)置為2 B，并進行讀寫比例為1:1 的實驗和統(tǒng)計。數(shù)據(jù)副本地理位置均設(shè)置在本地，但實際存儲環(huán)境中云服務(wù)商往往鍵副本部署在世界各地，以滿足不同區(qū)域用戶的需求。為了使CCT 模型的性能開銷更加明確，實驗在本地手動設(shè)置了副本間的時鐘時延，即對分區(qū)間地理位置差異造成的通信時延進行模擬，并在分區(qū)間不同通信時延的條件下對更新可見性時延進行統(tǒng)計和分析。4.1 節(jié)和4.2 節(jié)實驗已對服務(wù)端安全約束、客戶端的安全機制進行了驗證與測試，因此本節(jié)只在可信云服務(wù)器環(huán)境中對安全約束進行性能開銷的測試和分析，并對未對身份偽造或數(shù)據(jù)篡改風(fēng)險進行模擬，實驗將操作數(shù)設(shè)置為1 000 個，每個數(shù)據(jù)均是3 次實驗所取的平均值，其中累積分布函數(shù)（CDF,cumulative distribution function）指的是與主控節(jié)點通信時延小于當(dāng)前最大時延閾值的分區(qū)比例，結(jié)果如圖7 所示。

圖7 分區(qū)間時延閾值為10 ms 時不同模型的性能開銷

實驗中通過在分區(qū)間設(shè)置不同通信時延，模擬不同地理位置之間服務(wù)器的通信開銷，對不同數(shù)據(jù)因果一致性方案的性能開銷進行了分析。圖7(a)為CCT 模型與GentleRain 之間的對比，結(jié)果顯示CCT模型明顯優(yōu)于GentleRain，因為使用混合邏輯時鐘能避免時鐘漂移、網(wǎng)絡(luò)時鐘協(xié)議（NTP,network time protocol）同步失敗帶來的安全風(fēng)險，結(jié)合HashGraph 共識機制，分區(qū)穩(wěn)定狀態(tài)在拓撲樹中快速形成共識。圖7(b)結(jié)果為參照文獻[7]中數(shù)據(jù)，并在低通信時延環(huán)境下將GentleRain 方案復(fù)現(xiàn)并測試，同時對比CausalSpartan，可見CCT 模型的更新可見時延比 Saturn 平均降低了 45.03%，比CausalSpartan 平均增加了10.86%。

Saturn 由于在客戶端請求發(fā)送的關(guān)鍵路徑上使用標(biāo)簽序列化為客戶端和服務(wù)端提供雙向追蹤依賴集的因果序的依據(jù)，并且在處理客戶端請求過程中通過構(gòu)建一棵優(yōu)化的結(jié)構(gòu)樹的方式降低通信開銷，有一定的性能瓶頸。CCT 模型基于可信云聯(lián)盟技術(shù)，提供可信約束的前提下并未局限于TPM 的性能瓶頸，且結(jié)合HLC 同步方法有效降低了時鐘時延和通信時延造成的操作處理時延。因此CCT模型在較理想的環(huán)境中性能開銷明顯低于Saturn，證明3.1 節(jié)中結(jié)合HashGraph 對可信證據(jù)的同步機制進行優(yōu)化的方案是可行的。

在CausalSpartan 方案中，同樣使用分區(qū)穩(wěn)定向量標(biāo)識分區(qū)最新狀態(tài)，并且都依據(jù)HLC 判別用戶存取數(shù)據(jù)事件的因果序。雖然CCT 模型中對集群拓撲結(jié)構(gòu)中數(shù)據(jù)的同步方式結(jié)合HashGraph 共識機制設(shè)計了優(yōu)化方案，對PUT 和GET 的事件使用Gossip about Gossip 進行同步的方式降低了分區(qū)間數(shù)據(jù)、狀態(tài)同步過程的時間開銷，但是客戶端與服務(wù)端之間的身份簽名、數(shù)據(jù)可信證據(jù)驗證機制消耗了一定性能，因而在低時延環(huán)境中CCT 模型的更新可見性時延也是略高于CausalSpartan。

最后一部分實驗?zāi)M了相同副本和分區(qū)規(guī)模情況下的高通信時延環(huán)境，為了使數(shù)據(jù)對比Saturn模型具有權(quán)威性，分區(qū)時延閾值設(shè)置為107 ms，每個對比數(shù)據(jù)均為進行1 000 個操作負載后3 次結(jié)果的平均值。圖8 結(jié)果表明，在分區(qū)間通信最低為10 ms，按比例遞增至全分區(qū)通信時延為107 ms 的情況中，CCT 模型的性能表現(xiàn)明顯優(yōu)于Saturn、GentleRain，比未提供安全約束的CausalSpartan 略高。

圖8 分區(qū)間時延閾值為107 ms 時不同模型的性能開銷

具體看來，Saturn 在高通信時延環(huán)境中的更新可見時延接近于使用物理時鐘標(biāo)量追蹤因果序的GentleRain，通信時延接近107 ms 的分區(qū)占總數(shù)比例為10%～80%時，兩者更新可見時延非常接近，但在高于80%時，GentleRain 模型嚴(yán)格依賴物理時鐘同步的缺陷就非常明顯了。Saturn 模型在所有比例環(huán)境中表現(xiàn)相對穩(wěn)定，因為該方案使用序列化的元數(shù)據(jù)標(biāo)簽判別因果序并提供安全約束、構(gòu)建一棵優(yōu)化的結(jié)構(gòu)樹的方式在分區(qū)規(guī)模增大時具有較明顯的性能頸。CCT 模型采用混合邏輯時鐘判別事件之間的因果序，在分區(qū)間時鐘漂移、通信時延較高的情況下均有非常優(yōu)秀的表現(xiàn)，同樣包含安全約束的前提下在高通信時延環(huán)境中的更新可見時延比Saturn 平均降低了32.31%，且比GentleRain 平均降低32.92%。而在模擬實際云環(huán)境的分區(qū)間高通信時延條件下，與低通信時延條件下情況類似，CCT 模型的更新可見時延比CausalSpartan 模型平均增加了10.54%。

5 結(jié)束語

云服務(wù)商在為用戶提供因果一致性數(shù)據(jù)存取服務(wù)時，采用分布式服務(wù)器在降低運營成本的同時也可滿足用戶的多樣化需求，但針對分布式服務(wù)器、客戶端中的身份簽名偽造、數(shù)據(jù)竊聽或篡改等安全風(fēng)險鮮有考慮。CCT 模型基于Java 實現(xiàn)，結(jié)合混合邏輯時鐘和HashGraph 共識機制的優(yōu)化方案，并使用分區(qū)穩(wěn)定向量標(biāo)識分區(qū)最先狀態(tài)，基于可信云平臺中可信認證機制，在服務(wù)端和客戶端設(shè)計了身份簽名可信驗證、一致性元數(shù)據(jù)完整性驗證等可信約束。通過仿真實驗表明，CCT 模型針對安全風(fēng)險能全部識別并記錄，存在較低的誤檢測率和較小的性能開銷。相比于使用標(biāo)簽序列化保障數(shù)據(jù)安全的方案Saturn，更新可見性時延明顯降低。實驗結(jié)果表明，CCT 模型中設(shè)計的可信約束是具有可行性的。相比于未提供安全約束的CausalSpartan，CCT 模型的更新可見時延也僅增加了10%左右。在實際分布式數(shù)據(jù)存儲環(huán)境中，考慮到用戶因果一致性敏感數(shù)據(jù)的安全性，結(jié)合可信云平臺、可信認證機制設(shè)計安全約束所造成的較小性能開銷是可以接受的。