王 強，宗 平

(1.南京郵電大學(xué) 計算機學(xué)院，江蘇 南京 210003；2.南京郵電大學(xué) 海外教育學(xué)院，江蘇 南京 210023)

云存儲中基于可信第三方的安全可問責(zé)方案

王 強1，宗 平2

(1.南京郵電大學(xué) 計算機學(xué)院，江蘇 南京 210003；2.南京郵電大學(xué) 海外教育學(xué)院，江蘇 南京 210023)

隨著云存儲的普及和發(fā)展，云端數(shù)據(jù)的安全問題越來越受到人們的關(guān)注。針對當(dāng)存儲在云端服務(wù)器中的數(shù)據(jù)文件遭到非法修改或意外損壞時，云存儲用戶與云端均無法提供使雙方信服的憑據(jù)進行責(zé)任劃分的問題，提出了一種基于可信第三方的數(shù)據(jù)安全可問責(zé)方案。該方案以可信第三方為審計的核心與橋梁，在用戶與云端任何一方對數(shù)據(jù)狀態(tài)持有異議時進行責(zé)任追溯。可信第三方針對每次用戶數(shù)據(jù)操作都通過在線狀態(tài)判斷并經(jīng)相應(yīng)文件權(quán)限認證，只有通過可信第三方在線狀態(tài)與文件權(quán)限審核的用戶數(shù)據(jù)操作才能被系統(tǒng)所認可，并將操作記錄保存在雙方都無法抵賴的憑據(jù)中。實現(xiàn)了利用可信第三方代替用戶執(zhí)行數(shù)據(jù)審計與問責(zé)，可靠并高效地解決了用戶對數(shù)據(jù)狀態(tài)持有異議但無法追溯的問題。

云存儲；可信第三方；審計；問責(zé)；數(shù)據(jù)安全

1 概 述

云存儲是以存儲數(shù)據(jù)和管理數(shù)據(jù)為核心的云計算系統(tǒng)，是由云計算衍生出來的一種網(wǎng)絡(luò)存儲技術(shù)。云存儲系統(tǒng)通過網(wǎng)絡(luò)技術(shù)、集群、分布式文件系統(tǒng)、存儲虛擬化、存儲網(wǎng)絡(luò)化等技術(shù)，將網(wǎng)絡(luò)中大量各種不同類型的存儲設(shè)備通過應(yīng)用軟件集合起來協(xié)同工作，共同對外提供數(shù)據(jù)存儲和業(yè)務(wù)訪問功能，從而將軟硬件資源有限的用戶從復(fù)雜繁重的數(shù)據(jù)計算和管理任務(wù)中解放出來。云存儲的體系結(jié)構(gòu)分層模型參見圖1。

在云存儲中，當(dāng)用戶將數(shù)據(jù)儲存到云服務(wù)器時，也就意味著失去了對數(shù)據(jù)的絕對控制權(quán)。因此，數(shù)據(jù)安全是一個不可忽視的問題。云存儲系統(tǒng)中數(shù)據(jù)的安全性可分為存儲安全性和傳輸安全性兩部分，每部分均包含數(shù)據(jù)可用性、數(shù)據(jù)機密性和數(shù)據(jù)完整性三個方面。數(shù)據(jù)可用性是指在一定級別的存儲系統(tǒng)環(huán)境中，數(shù)據(jù)必須是可用的。數(shù)據(jù)機密性是指數(shù)據(jù)的明文在傳輸和存儲的過程中不能被其他任何用戶和云服務(wù)提供商(Cloud Service Provider，CSP)訪問，只有數(shù)據(jù)擁有者和被授權(quán)用戶才能訪問數(shù)據(jù)明文。數(shù)據(jù)完整性[1]涉及數(shù)據(jù)存儲時完整性和數(shù)據(jù)使用時完整性兩個方面。數(shù)據(jù)存儲時完整性是指云存儲服務(wù)提供商是按照用戶的要求將數(shù)據(jù)完整地保存在云端，不能有絲毫的損壞或丟失。數(shù)據(jù)使用時完整性是指當(dāng)用戶對某個已有權(quán)限的數(shù)據(jù)進行操作時，此數(shù)據(jù)沒有被篡改或偽造。

圖1 云存儲系統(tǒng)結(jié)構(gòu)模型

數(shù)據(jù)的完整性是當(dāng)前用戶將數(shù)據(jù)存儲在云端所要考慮的一個重要方面。一方面，存儲在云端的數(shù)據(jù)易被黑客攻擊或被云服務(wù)提供商的內(nèi)部人員惡意篡改，并且由于不同用戶之間所持有的數(shù)據(jù)資源通常采用邏輯的方式隔離，因此惡意的攻擊者可以通過偽裝成合法用戶從內(nèi)部發(fā)起攻擊，竊取或破壞其他用戶的數(shù)據(jù)。另一方面，云服務(wù)提供商并不能保證云端軟件或硬件一直處于正常運行狀態(tài)，因此一些不可避免的因素也會導(dǎo)致數(shù)據(jù)的損壞。同時，由于缺乏監(jiān)管，云服務(wù)提供商出于利益的考慮可能會隱瞞用戶數(shù)據(jù)的丟失或損壞，甚至泄露用戶的敏感數(shù)據(jù)，并且使用戶相信他們的數(shù)據(jù)仍然被安全完整地存儲在云服務(wù)器上[2-3]。因此，數(shù)據(jù)的完整性問題是云存儲數(shù)據(jù)安全方面不可忽視的重要問題之一。

雖然用戶在使用云存儲服務(wù)之前會與云服務(wù)提供商訂立相應(yīng)合約，但是合約的履行缺乏實際監(jiān)督，所以當(dāng)數(shù)據(jù)遭到破壞，或者用戶對數(shù)據(jù)的狀態(tài)提出疑問時，雙方均無法提供一個可信的憑據(jù)進行責(zé)任劃分。因此，建立一個完善的數(shù)據(jù)監(jiān)督和問責(zé)機制來對用戶和云端進行行為監(jiān)督，不僅能夠加強用戶與云服務(wù)提供商之間的信任，還能及時準確的解決云端數(shù)據(jù)產(chǎn)生的糾紛問題[4-5]。

為了將云服務(wù)和問責(zé)技術(shù)結(jié)合起來，在云存儲環(huán)境下建立了一個完善的問責(zé)機制。Andreas Haeberlen[6]和Siani Pearson[7]在云計算的基礎(chǔ)上歸納總結(jié)出了問責(zé)機制的基本需求，并提出了問責(zé)機制的設(shè)計框架和潛在的技術(shù)挑戰(zhàn)等。Ryan等[8]進一步完善了可信云計算中問責(zé)機制的框架，并提出了云問責(zé)的生命周期以及三個抽象層。Volkmar等[9]提出云問責(zé)需要在更加多樣的安全機制和更加嚴格的業(yè)務(wù)流程中進行。Mainul Mizan等[10]提出一種基于時間屬性安全問責(zé)的大規(guī)?？蓴U展系統(tǒng)。Zou Jun等[11]提出一種可問責(zé)云服務(wù)模型(Accountable Cloud Service，ACS)，該模型是由動態(tài)邏輯系統(tǒng)擴展而來的可問責(zé)的動態(tài)邏輯混合系統(tǒng)。

基于上述考慮，文中提出一種基于可信第三方的驗證在線狀態(tài)和權(quán)限的可問責(zé)方案。該方案以可信第三方作為問責(zé)和審計流程的核心，對用戶提出的文件操作請求進行在線狀態(tài)和文件權(quán)限驗證。同時，在云端將用戶提出的相應(yīng)操作執(zhí)行完畢后，可信第三方將雙方用于確認操作的簽名和操作記錄保存在憑據(jù)中，從而保證了審計結(jié)果的不可抵賴性。

2 基于可信第三方的可問責(zé)方案

2.1方案架構(gòu)設(shè)計

提出了一種基于可信第三方(Trusted Third Party，TTP)的可問責(zé)系統(tǒng)。一個可靠的可信第三方問責(zé)系統(tǒng)需要提供以下三個功能[12-13]：

(1)用戶對云端數(shù)據(jù)的任何操作在可信第三方和云端均有記錄；

(2)當(dāng)出現(xiàn)糾紛時，可信第三方能夠準確查找到糾紛責(zé)任方，并進行責(zé)任判定

(3)用于判斷責(zé)任方的憑證具有無法抵賴性和無法推卸性。

因此，每次用戶、云端和可信第三方交互時，可信第三方都會新建或更新一種用于問責(zé)審計時不可抵賴的憑單。

云存儲中基于可信第三方的數(shù)據(jù)完整性問責(zé)方案主要在用戶(User)、云服務(wù)提供商、可信第三方這三個角色之間執(zhí)行。云服務(wù)提供商提供云存儲以及周邊相關(guān)服務(wù)。用戶使用云存儲服務(wù)，將文件數(shù)據(jù)等存儲在云端?？尚诺谌截撠?zé)監(jiān)督用戶和云端的行為，并記錄每次數(shù)據(jù)操作，當(dāng)出現(xiàn)糾紛時，可信第三方可出具不可抵賴的問責(zé)憑據(jù)，并判斷責(zé)任方。

用戶通過瀏覽器或者其他客戶端對云端文件進行操作?？尚诺谌降姆?wù)器數(shù)據(jù)庫中存有云端文件訪問控制列表、文件加密解密密鑰表、問責(zé)憑單列表以及用戶臨時令牌表。云端存儲文件和文件操作記錄表等其他數(shù)據(jù)。同時，對于除文件以外的數(shù)據(jù)，在傳輸時均要進行加密，為此每方都持有己方的私鑰和另外兩方的公鑰。

用戶每次通過瀏覽器或其他客戶端登錄云端時，都會從可信第三方處獲得一個臨時令牌token。當(dāng)用戶一段時間未進行數(shù)據(jù)操作或退出登錄時，可信第三方會將該用戶對應(yīng)的臨時令牌token重置。用戶在對云端數(shù)據(jù)進行操作時，都會將緩存在客戶端的臨時令牌加密后發(fā)送給可信第三方。可信第三方將收到的token解密后與用戶臨時令牌表中的對應(yīng)記錄進行比對，在匹配成功后，可信第三方會通過文件訪問控制表驗證用戶是否擁有被訪問文件的訪問權(quán)限。只有上述驗證全部通過后，用戶才能被可信第三方和云端認可并進行后續(xù)的操作。當(dāng)云端對用戶的請求進行響應(yīng)后，用戶均會通過客戶端對云服務(wù)器上請求操作的數(shù)據(jù)進行在線檢查。用戶確認操作數(shù)據(jù)成功后會發(fā)送確認信息給可信第三方進行用戶方確認。

每次用戶對文件進行操作后，可信第三方都會生成新密鑰對文件進行加密，并更新文件密鑰版本。因此在進行數(shù)據(jù)共享時，可信第三方只需維護文件訪問控制列表，無需管理文件密鑰與用戶的關(guān)系。同時，文件密鑰表的使用，使得密鑰的生成算法被獨立分割出來，即加密和密鑰生成算法不依賴于系統(tǒng)，相對獨立。因此，系統(tǒng)可使用多種密鑰生成算法來生成密鑰。

用戶和云端對數(shù)據(jù)的每次操作都會生成問責(zé)憑單項，并保存在可信第三方的憑單表中。當(dāng)用戶提出問責(zé)或雙方出現(xiàn)糾紛時，可信第三方將根據(jù)云端的文件操作記錄和本地的憑單來進行責(zé)任判斷?；诳尚诺谌降臄?shù)據(jù)完整性問責(zé)架構(gòu)如圖2所示。

圖2 基于可信第三方的可問責(zé)架構(gòu)

2.2憑單設(shè)計

可信第三方的憑單表(Credential Table，CT)中記錄了云端每個文件的憑單鏈表(Credential List，CL)，其結(jié)構(gòu)如圖3所示。

圖3 憑單鏈表

這些憑單鏈表和文件是一一對應(yīng)的關(guān)系。憑單鏈表的表頭節(jié)點(Credential Head，CH)保存了該憑單鏈表的基本信息。user_id為文件擁有者的唯一標(biāo)識；file_id為該憑單鏈表對應(yīng)文件的唯一標(biāo)識；timestamp為最近一次操作文件的時間戳；kversion_num為該文件的密鑰版本數(shù)，即密鑰最大版本號；fversion_num為該文件版本數(shù)，即文件最大版本號；len為CL不包括CH的剩余長度；next_cn為該表頭節(jié)點的下一個憑據(jù)節(jié)點(Credential Node，CN)的編號。憑據(jù)節(jié)點中保存了每一次文件操作的基本信息，cn_num為該節(jié)點的編號；user_id為操作文件用戶的唯一標(biāo)識；file_id為文件的唯一標(biāo)識；TYPE為文件操作類型，該類型為枚舉型，包含CREATE、DETELE、READ、UPDATE四種類型；timestamp為此次操作的時間戳；key_version和file_version分別對應(yīng)操作完成后的密鑰版本號和文件版本號；user_sign、cloud_sign、tp_sign分別為用戶簽名、云端簽名、可信第三方簽名，用來保證憑據(jù)的不可抵賴性和完整性；next_cn為該憑據(jù)節(jié)點的下一個憑據(jù)節(jié)點的編號。

2.3用戶登錄流程

為了防止云端內(nèi)部偽裝成合法用戶登錄系統(tǒng)，從而欺騙可信第三方進行數(shù)據(jù)操作，所采用方案的用戶登錄管理權(quán)限由可信第三方來執(zhí)行。用戶在登錄時，將登錄數(shù)據(jù)發(fā)送給可信第三方進行審核。審核通過后，可信第三方會將用戶登錄數(shù)據(jù)按照事先與云端商量好的格式進行打包，并發(fā)送給云端。云端記錄用戶登錄狀態(tài)，并返回用戶此次在線期間內(nèi)數(shù)據(jù)交互時需要的臨時數(shù)據(jù)。最后，可信第三方將云端返回的數(shù)據(jù)連同臨時令牌token和用戶私鑰一起返回給用戶。用戶將這些數(shù)據(jù)信息進行緩存或保存到臨時文件中。

2.4數(shù)據(jù)交互流程

2.4.1 基礎(chǔ)交互架構(gòu)

User、CSP和TTP三方進行數(shù)據(jù)交互時，首先User會向CSP發(fā)送文件操作請求，如果此時操作類型為“新建”或“更新”，則需同時上傳文件。與此同時，User會向TTP發(fā)送密鑰申請請求以及在線標(biāo)識。TTP在收到User發(fā)來的數(shù)據(jù)后驗證User在線狀態(tài)，并進行密鑰表操作，隨后向CSP發(fā)送密鑰和其他附加數(shù)據(jù)。CSP收到密鑰后進行相應(yīng)文件操作，并告知User操作結(jié)果，同時向TTP發(fā)送表示操作完成的簽名。User收到CSP的文件操作完成后進行檢查，并向TTP發(fā)送表示檢查結(jié)果的簽名。具體流程如圖4所示。

2.4.2 創(chuàng)建新文件流程

User在創(chuàng)建新的文件對象時，首先向CSP和TTP發(fā)送通過私鑰加密后的請求。向CSP發(fā)送新文件、user_id、file_id、timestamp，向TTP發(fā)送的是申請第三方向云端發(fā)送加密密鑰的請求，該請求包括值為“CREATE”的TYPE、在線標(biāo)識token以及file_id、user_id、timestamp。

TTP收到User發(fā)來的發(fā)送密鑰請求后，利用User公鑰對請求進行解密，隨后識別user_id和token是否匹配。匹配通過后，TTP新建與user_id和file_id對應(yīng)的文件密鑰表，并將利用密鑰生成算法生成的密鑰對保存在該表中。最后，TTP利用己方私鑰將加密密鑰與file_id進行加密，向CSP發(fā)送。

圖4 基礎(chǔ)交互架構(gòu)

CSP在收到User和TTP發(fā)來的數(shù)據(jù)后，先對TTP發(fā)來的數(shù)據(jù)進行解密，然后利用密鑰對User發(fā)來的文件進行加密和存儲。隨后向User發(fā)送“SUCCESS_CREATE”字段表示新建文件對象成功，并將user_id、file_id以及初始操作編號“1”加密作為簽名發(fā)送給TTP。如果CSP新建文件失敗，則發(fā)送“FAILED_CREATE”字段給User，并將user_id、file_id以及失敗編號“0”加密作為簽名發(fā)送給TTP。

User收到CSP的創(chuàng)建文件對象響應(yīng)后，直接通過瀏覽器或其他客戶端檢查文件對象是否新建成功。如果檢查通過，則將user_id、file_id以及初始操作編號“1”加密作為簽名發(fā)送給TTP；否則，將user_id、file_id以及未通過檢查標(biāo)識“0”加密作為簽名發(fā)送給TTP。

TTP收到User和CSP發(fā)來的簽名后，根據(jù)與此次操作相關(guān)的file_id、user_id、timestamp、TYPE、user_sign、cloud_sign，創(chuàng)建一個只含一個CN的CL，其中CH的kversion_num、fversion_num、len和next_cn置1，CN的key_version、file_version、cn_num置1，next_cn置空，tp_sign中保存的是利用TTP私鑰加密user_id、file_id、key_version和file_version生成的TTP簽名。

2.4.3 讀取文件流程

User在讀取文件對象時，同時向CSP和TTP發(fā)送私鑰加密過的請求。向CSP發(fā)送的讀文件請求包括user_id、file_id和timestamp，向TTP發(fā)送的是申請TTP向云端發(fā)送解密密鑰的請求，該請求包括值為“READ”的TYPE、在線標(biāo)識token以及file_id、user_id、timestamp。

TTP在收到User的發(fā)送密鑰請求后，首先驗證User是否擁有對應(yīng)文件的讀權(quán)限，并匹配User的token是否正確。通過驗證后，TTP在對應(yīng)file_id的CL中查找最新CN的cn_num和key_version，并在文件密鑰表中查找該key_version的解密密鑰。同時，TTP利用密鑰生成算法生成一對新的密鑰對保存到文件密鑰表中。最后，TTP將該舊解密密鑰、新解密密鑰、file_id以及最新CN的cn_num進行加密后發(fā)送給CSP。

CSP在收到User發(fā)來的讀取請求和TTP發(fā)來的數(shù)據(jù)后，對文件進行解密。待解密成功后，將文件、最新CN的cn_num和“SUCCESS_READ”字段一并發(fā)送給User所使用的客戶端。隨后利用新的加密密鑰將解密完成后的文件進行重新加密。同時，CSP將user_id、file_id和cn_num+1加密作為簽名發(fā)送給TTP。如果操作失敗，則向User發(fā)送“FAILED_READ”字段，并將user_id、file_id和失敗編號“0”加密作為簽名發(fā)送給TTP。

User收到CSP的讀取文件響應(yīng)后，直接通過客戶端檢查文件對象是否是自己期望的內(nèi)容和版本，如果檢查通過，User將user_id、file_id和cn_num+1加密作為簽名發(fā)送給TTP。否則，將user_id、file_id以及未通過檢查標(biāo)識“0”加密作為簽名發(fā)送給TTP。

TTP收到User和CSP發(fā)來的簽名后，根據(jù)與此次操作相關(guān)的file_id、user_id、timestamp、TYPE、user_sign、cloud_sign生成CN，該CN的key_version和file_version均為最新的版本號。同時，該CN中的tp_sign保存的是利用TTP私鑰加密user_id、file_id、key_version和file_version生成的TTP簽名。最后，TTP將該CN插入到對應(yīng)CL的CH后，更新CH中的timestamp、kversion_num、fversion_num、len和next_cn。

2.4.4 更新文件流程

User在更新文件對象時向CSP和TTP發(fā)送通過私鑰加密后的請求，向CSP發(fā)送的請求包括更新的文件、file_id、user_id、timestamp，向TTP發(fā)送的是申請第三方向云端發(fā)送加密密鑰的請求，該請求包括值為“UPDATE”的TYPE、在線標(biāo)識token以及file_id、user_id和timestamp。

TTP在收到User發(fā)來的發(fā)送密鑰請求后，利用User公鑰對請求進行解密，隨后驗證User是否擁有對應(yīng)文件的寫權(quán)限，并識別user_id和token是否匹配。匹配通過后,TTP在對應(yīng)file_id的CL中查找最新CN的cn_num，同時，TTP利用密鑰生成算法生成一對新的密鑰對保存到文件密鑰表中。最后，TTP將新加密密鑰、cn_num、file_id進行加密后發(fā)送給CSP。

CSP在收到User發(fā)來的更新文件和TTP發(fā)來的數(shù)據(jù)后，對原文件進行更新和重新加密。隨后向用戶發(fā)送“SUCCESS_UPDATE”字段以及最新CN的cn_num，同時將user_id、file_id和cn_num+1加密作為簽名發(fā)送給可信第三方。如果CSP操作失敗，則向User發(fā)送“FAILED_UPDATE”字段，并將user_id、file_id以及失敗標(biāo)識“0”加密作為簽名發(fā)送給TTP。

User收到CSP的更新響應(yīng)后，直接通過客戶端檢查文件對象是否更新成功。如果檢查通過，User將user_id、file_id和cn_num+1加密作為簽名發(fā)送給TTP，否則，將user_id、file_id以及未通過檢查標(biāo)識“0”加密作為簽名發(fā)送給TTP。

TTP收到User和CPS發(fā)來的簽名后，根據(jù)與此次操作相關(guān)的file_id、user_id、timestamp、TYPE、user_sign、cloud_sign生成CN，該CN的key_version和file_version均為最新的版本號。同時，該CN中的tp_sign保存的是利用TTP私鑰加密user_id、file_id、key_version和file_version生成的TTP簽名。最后，TTP將該CN插入到對應(yīng)CL的CH后，更新CH中的timestamp、kversion_num、fversion_num、len和next_cn。

2.4.5 刪除文件流程

User在刪除文件對象時，同時向CSP和TTP發(fā)送刪除文件請求。向CSP發(fā)送的刪除文件請求中包括user_id、file_id、timestamp，向TTP發(fā)送的是判斷是否有刪除文件的權(quán)限的請求，該請求包括值為“DETELE”的TYPE標(biāo)識、在線標(biāo)識token以及file_id、user_id和timestamp。

TTP在收到User的請求后，利用User公鑰對請求進行解密，隨后判斷User對文件是否有寫權(quán)限，并識別user_id和token是否匹配。匹配通過后，TTP向云端發(fā)送允許刪除文件的“DELETE_ALLOW”字段、cn_num、file_id。

CSP收到User刪除請求和TTP發(fā)來的“DELETE_ALLOW”字段后，刪除文件，并向User發(fā)送“SUCCESS_DELETE”字段以及最新CN的cn_num，同時將user_id、file_id和cn_num+1加密作為簽名發(fā)送給TTP。如果操作失敗，則向User發(fā)送“FAILED_DELETE”字段，并將user_id、file_id和失敗編號“0”加密作為簽名發(fā)送給TTP。

User收到CSP發(fā)來的刪除文件成功的消息后，通過客戶端檢查是否刪除成功，如果通過檢查，則將user_id、file_id和cn_num+1加密作為簽名發(fā)送給TTP，否則，將user_id、file_id以及未通過檢查標(biāo)識“0”加密作為簽名發(fā)送給TTP。

TTP收到User和CSP發(fā)來的簽名后，根據(jù)與此次操作相關(guān)的file_id、user_id、timestamp、TYPE、user_sign、cloud_sign生成CN，該CN的key_version和file_version均為最新的版本號。同時，該CN中的tp_sign保存的是利用TTP私鑰加密user_id、file_id、key_version和file_version生成的TTP簽名。最后，TTP將該CN插入到對應(yīng)CL的CH后，更新CH中的timestamp、kversion_num、fversion_num、len和next_cn。

2.5審計和問責(zé)流程

當(dāng)User對文件內(nèi)容或版本有異議時，可向TTP提出問責(zé)審計請求。TTP首先會判別User是否具有權(quán)限對文件進行讀或?qū)?。?dāng)User權(quán)限不夠時，TTP拒絕此次審計請求，并告知User原因。TTP還會判斷User申請審計的文件版本是否合理，如果申請的版本小于對應(yīng)憑單鏈表中記錄的版本，則拒接此次審計請求，并告知User原因。

TTP要求CSP提供用戶請求審計的相應(yīng)版本文件以及云端記錄的該文件的操作歷史。如果CSP無法提供文件或操作記錄的任何一個，則判別為CSP責(zé)任，并告知User原因。

TTP根據(jù)文件對應(yīng)版本的內(nèi)容，以及CL中和CSP提供的文件操作記錄進行責(zé)任判別。通過CL長度與文件操作記錄的數(shù)量判別文件是否被其他非法用戶進行額外操作；通過檢查CN中的user_sign、cloud_sign、tp_sign判別各方是否承認對應(yīng)操作成功；通過檢查文件內(nèi)容判別文件是否在逃避記錄的情況下被修改。審計問責(zé)流程如圖5所示。

圖5 審計和問責(zé)流程

3 安全性分析

云存儲可問責(zé)系統(tǒng)主要關(guān)注導(dǎo)致數(shù)據(jù)文件處于某個狀態(tài)的緣由，即對數(shù)據(jù)文件的各種操作。在面臨安全問題時，可問責(zé)系統(tǒng)能夠根據(jù)對文件的操作記錄進行審計和問責(zé)。表1列出了系統(tǒng)可能面臨的安全問題以及審計方法。

(1)云端執(zhí)行用戶操作失敗或返回錯誤的響應(yīng)碼。

云端收到用戶的操作請求后，進行一系列的數(shù)據(jù)處理，隨后將處理結(jié)果提供給用戶進行檢查。只有通過用戶檢查確認，此次數(shù)據(jù)操作才被認可。同時，可信第三方會將用戶的確認信息記錄在憑據(jù)中，以便后續(xù)審計使用。

表1 可問責(zé)系統(tǒng)面臨的安全問題和審計方法

(2)用戶或云端否認文件的創(chuàng)建、刪除、更新。

可信第三方保存的憑單鏈表中保存了用戶與云端每次交互生成的數(shù)據(jù)信息。用戶簽名、云端簽名以及可信第三方簽名更是三方均不可抵賴的確認憑據(jù)。同時，當(dāng)云端數(shù)據(jù)出現(xiàn)了憑單鏈表中無法檢查到的更改時，可認為數(shù)據(jù)被非法用戶更改，為云端責(zé)任。

(3)非法創(chuàng)建、刪除、更新。

若一個訪問者不在被操作文件的訪問控制列表中，但仍能對文件進行讀或?qū)?，則該訪問者可認為是非法用戶。非法用戶在對數(shù)據(jù)進行操作時，即使在云端和可信第三方中均沒有留下操作痕跡，但在審計階段對文件內(nèi)容進行檢查時，仍可發(fā)現(xiàn)文件被篡改，因此可判斷為云端責(zé)任。

(4)非法登陸系統(tǒng)。

為了防止云端模擬用戶登錄系統(tǒng)，系統(tǒng)的登錄權(quán)限由可信第三方進行管理控制，云端不持有用戶的登錄密鑰。

(5)非法讀取文件。

可信第三方中保存并控制文件的讀寫權(quán)限。正常用戶向云端和可信第三方發(fā)起文件讀取請求時，都會被可信第三方進行權(quán)限檢查。同時，為了防止非法用戶繞過可信第三方對云端數(shù)據(jù)進行直接讀取，云端將數(shù)據(jù)采取一次一密的加密方式。即使非法用戶獲取到解密密鑰，但下次讀取時數(shù)據(jù)的密鑰對已經(jīng)更換，從而保證了云端數(shù)據(jù)的安全性。

4 結(jié)束語

隨著云計算的發(fā)展，云存儲的安全問題必然受到更多的需求和關(guān)注。在云計算數(shù)據(jù)存儲環(huán)境下提出了可信第三方的概念，利用可信第三方監(jiān)督云端與用戶之間的數(shù)據(jù)交互，并作為中間方進行公平公正的審計與問責(zé)。方案中使用一種不可更改的憑單鏈表來記錄用戶對云端數(shù)據(jù)的操作。鏈表由可信第三方保存，用戶和云端均無權(quán)修改，從而保證了憑據(jù)的安全性。同時，方案提出了一種基于用戶在線的憑單生成協(xié)議，在每次進行數(shù)據(jù)交互時，可信第三方都會對用戶的在線狀態(tài)和token進行驗證，只有用戶在線且持有正確的token時，可信第三方才認可用戶對數(shù)據(jù)的操作?？尚诺谌絻H負責(zé)生成、保存和發(fā)送密鑰，對于具體的密鑰生成算法并沒有嚴格限制，大大增強了該方案的可用性和可擴展性。

[1] 馮登國,張 敏,張 妍,等.云計算安全研究[J].軟件學(xué)報,2011,22(1):71-83.

[2] Ateniese G,Burns R,Curtmola R,et al.Remote data checking using provable data possession[J].ACM Transactions on Information and System Security,2011,14(1):12.

[3] Wang Q,Wang C,Li J,et al.Enabling public variability and data dynamics for storage security in cloud computing[C]//Proceedings of ESORICS.[s.l.]:[s.n.],2009:355-370.

[4] Riedel E,Kallahalla M,Swaminathan R.A framework for evaluating storage system security[C]//Proceedings of the conference on file and storage technologies.Berkley:USENIX Association,2002:15-30.

[5] Kamara S, Lauter K. Cryptographic cloud storage financial cryptography and data security[C]//Proceedings of the 14th international conference on financial cryptography and data security.Berlin:Springer,2010:136-149.

[6] Haeberlen A.A case for accountable cloud[J].ACM SIUOPS Operating Systems Review,2010,44(2):52-57.

[7] Pearson S.Toward accountability in the cloud[J].IEEE Internet Computing,2011,15(4):64-69.

[8] Ko R K L,Bu S L,Pearson S.Towards achieving accountability,auditability and trust in cloud computing[C]//Proceedings of international conference on ad-vances in computing and communications.[s.l.]:[s.n.],2011:432-444.

[9] Sendor J,Lotz V,de Oliveira A S.Control as a means towards accountable services in the cloud[J].Computer Systems Science and Engineering,2013,28(6):377-386.

[10] Mizan M,Rahman M L,Khan R,et al.Accountable proof of ownership for data using timing element in cloud services[C]//International conference on high performance computing and simulation.[s.l.]:IEEE,2013:57-64.

[11] Zou J,Wang Y,Orgun M A.Modeling accountable cloud services based on dynamic logic for accountability[J].International Journal of Web Services Research,2015,12(3):48-77.

[12] Yao J H,Chen S P,Wang C,et al.Accountability as a service for the cloud[C]//Proceedings of IEEE international conference on services computing.[s.l.]:IEEE,2010:81-88.

[13] Yemerefendi A R,Chase J S.Strong accountability for network storage[J].ACM Transactions on Storage,2007,3(3):11-33.

ADataSecurityAccountabilitySchemewithTrustedThirdPartyinCloudStorage

WANG Qiang1,ZONG Ping2

(1.College of Computer,Nanjing University of Posts and Telecommunications,Nanjing 210003,China; 2.College of Overseas Education,Nanjing University of Posts and Telecommunications,Nanjing 210023,China)

With the popularity and development of cloud storage,the security of the data in the cloud has been paid more and more attention.In view of the problem that the user and the cloud service provider cannot offer convincing credentials to duty partition when the data stored in the cloud has been unlawful modification or accidental damage,a data security accountability scheme based on trusted third party is put forward.It,which takes the trusted third party as the core and bond,traces the responsibility when any party has objection.For every user data operations,trusted third party is through the online status judgment and authenticated by the corresponding file permissions.The user data operations only by the trusted third party online status and user data file permissions audit can be accepted by the system and their records are stored in the credentials which the both couldn’t deny.It uses the trusted third party instead of users to audit and account,and solves the problem reliably and efficiently that the user disagree the data state but cannot trace back.

cloud storage;trusted third party;audit;accountability;data security

TP301

A

1673-629X(2017)10-0111-06

2016-11-18

2017-03-09 < class="emphasis_bold">網(wǎng)絡(luò)出版時間

時間：2017-07-19

教育部專項研究項目(2013116)

王 強(1991-)，男，碩士研究生，研究方向為云計算、云存儲數(shù)據(jù)完整性；宗 平，教授，研究方向為云計算與數(shù)據(jù)處理。

http://kns.cnki.net/kcms/detail/61.1450.TP.20170719.1112.070.html

10.3969/j.issn.1673-629X.2017.10.024