• 沒有找到結果。

相關研究探討

由於伺服器分散式儲存技術成熟,導致了雲端儲存的興起,使得使用者甚 至大型機構對於資料的存放除了自身的電腦設備以及自行建立的 NAS 外又多了 一種選擇,但是由於目前市面上提供雲端儲存服務的公司皆未在訂定的協議上

,保證醫院上傳的資料安全性,這對於極大量且具有敏感資料的病歷紀錄更是 一大風險,使得醫院對於節省成本與資料安全取捨的平衡性感到猶豫,以至於 研究者皆想要利用各式的架構或者協議來給這些更需要保護的資料多一分保障

在硬體方面,過往對於穿戴式物聯網感測器[15]上的應用仍在起步研究的 狀態,在未注重資料的隱私性與完整性的協定保護下,時常耳聞各種物聯網感 測器資盜遭受竊取甚至於被竄改,這時才發現到廠商在設計時完全沒有考慮資 料安全性疑慮,在[16]中使用 Raspberry-pi 作為中繼的伺服器,來處理眾多感測 器回傳的資料再統籌上傳至儲存服務商,但在資料處理流程中並沒有做如最基 本資料保護的加密的處理,日後這些資料從儲存服務商拿回來時,使用者沒有 辦法對這些資料做完整性檢查的稽核更不用說支援 POV 協定,雖然在沒有任何 保護之下資料傳遞的效率能夠最大化,但這也意即大幅增加傳送過程中遇到的 風險,使用者很有可能在此架構下從儲存服務商拿回來的資料,是已經被惡意 竄改過,但使用者卻沒有任何密碼學證據可以證明。

在其他篇論文做法中,[17][18]中應用了 provable data possession,假設了服 務供應商是不可信任,讓使用者能夠握有資料的證據,架構中讓使用者上傳資 料前對資料作前處理,並產生一個 metadata 自行保存,再將修飾過的資料上傳 至服務供應商,當使用者對服務供應商提出挑戰時,服務供應商必須計算 possession P 的證據,並給予使用者確認該證據是否正確,每上傳一筆資料使用 者都必須儲存該筆資料的 metadata,若資料數量巨大則會導致使用者過於消耗 儲存空間。

在[19]方法中,提出使用者的資料 tuple 透過 hash function 取得該資料雜湊 值後,再將多筆資料 tuples 的雜湊值用 Merkle hash tree[20]推算出根節點的 h(r

)做為完整性的證據,且利用公正第三方(Third-party)存放 Bloom filter[21]來 挑戰服務供應商某筆資料的存在與否,然而 Bloom filter 本身只能檢驗存在與否

,且存在著 false positive 的可能性,再來公正第三方存在著作弊的疑慮,使用者 想要對已存放的資料做更動,整體的流程相當的繁瑣,並不適用於使用者時常 上傳更新的應用場景下。

而[13]提到利用 Full binary hash tree(FBHTree)來實作對雲端儲存系統的 即時稽核架構如圖 7,使用者上傳的檔案之路徑作為 FBHTree 定位葉節點(leaf node)依據插入該筆資料的雜湊值再依序更新至 root,該架構的優勢在能夠支 援 POV 且使用者僅須保存 1 個 root hash 的雜湊值證據。

1 2

Tree node ID

圖 7 樹高為 4 的 FBHTree 與 hash map

但是反過來說,服務供應商除了要保存使用者的檔案外,必須額外保存其 檔案結構的 FBHTree 樹狀結構以及葉節點的 PB-pair,這點則會造成服務供應商 額外的儲存成本,若使用者更新資料的場景下,服務供應商必須將該更新資料

相關文件