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

王 強，宗 平

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

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

王 強1，宗 平2

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

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

云存儲；可信第三方；審計；問責；數據安全

1 概 述

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

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

圖1 云存儲系統結構模型

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

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

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

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

2 基于可信第三方的可問責方案

2.1方案架構設計

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

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

(2)當出現糾紛時，可信第三方能夠準確查找到糾紛責任方，并進行責任判定

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

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

云存儲中基于可信第三方的數據完整性問責方案主要在用戶(User)、云服務提供商、可信第三方這三個角色之間執行。云服務提供商提供云存儲以及周邊相關服務。用戶使用云存儲服務，將文件數據等存儲在云端。可信第三方負責監督用戶和云端的行為，并記錄每次數據操作，當出現糾紛時，可信第三方可出具不可抵賴的問責憑據，并判斷責任方。

用戶通過瀏覽器或者其他客戶端對云端文件進行操作。可信第三方的服務器數據庫中存有云端文件訪問控制列表、文件加密解密密鑰表、問責憑單列表以及用戶臨時令牌表。云端存儲文件和文件操作記錄表等其他數據。同時，對于除文件以外的數據，在傳輸時均要進行加密，為此每方都持有己方的私鑰和另外兩方的公鑰。

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

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

用戶和云端對數據的每次操作都會生成問責憑單項，并保存在可信第三方的憑單表中。當用戶提出問責或雙方出現糾紛時，可信第三方將根據云端的文件操作記錄和本地的憑單來進行責任判斷。基于可信第三方的數據完整性問責架構如圖2所示。

圖2 基于可信第三方的可問責架構

2.2憑單設計

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

圖3 憑單鏈表

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

2.3用戶登錄流程

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

2.4數據交互流程

2.4.1 基礎交互架構

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

2.4.2 創建新文件流程

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

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

圖4 基礎交互架構

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

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

TTP收到User和CSP發來的簽名后，根據與此次操作相關的file_id、user_id、timestamp、TYPE、user_sign、cloud_sign，創建一個只含一個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發送私鑰加密過的請求。向CSP發送的讀文件請求包括user_id、file_id和timestamp，向TTP發送的是申請TTP向云端發送解密密鑰的請求，該請求包括值為“READ”的TYPE、在線標識token以及file_id、user_id、timestamp。

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

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

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

TTP收到User和CSP發來的簽名后，根據與此次操作相關的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插入到對應CL的CH后，更新CH中的timestamp、kversion_num、fversion_num、len和next_cn。

2.4.4 更新文件流程

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

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

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

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

TTP收到User和CPS發來的簽名后，根據與此次操作相關的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插入到對應CL的CH后，更新CH中的timestamp、kversion_num、fversion_num、len和next_cn。

2.4.5 刪除文件流程

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

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

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

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

TTP收到User和CSP發來的簽名后，根據與此次操作相關的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插入到對應CL的CH后，更新CH中的timestamp、kversion_num、fversion_num、len和next_cn。

2.5審計和問責流程

當User對文件內容或版本有異議時，可向TTP提出問責審計請求。TTP首先會判別User是否具有權限對文件進行讀或寫。當User權限不夠時，TTP拒絕此次審計請求，并告知User原因。TTP還會判斷User申請審計的文件版本是否合理，如果申請的版本小于對應憑單鏈表中記錄的版本，則拒接此次審計請求，并告知User原因。

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

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

圖5 審計和問責流程

3 安全性分析

云存儲可問責系統主要關注導致數據文件處于某個狀態的緣由，即對數據文件的各種操作。在面臨安全問題時，可問責系統能夠根據對文件的操作記錄進行審計和問責。表1列出了系統可能面臨的安全問題以及審計方法。

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

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

表1 可問責系統面臨的安全問題和審計方法

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

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

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

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

(4)非法登陸系統。

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

(5)非法讀取文件。

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

4 結束語

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

[1] 馮登國,張 敏,張 妍,等.云計算安全研究[J].軟件學報,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">網絡出版時間

時間：2017-07-19

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

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

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

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