國立臺灣師範大學

資訊工程研究所碩士論文

指導教授： 黃冠寰 博士

物聯網之快速稽核與違約證明架構

Fast Audit and Proof-of-Violation Architecture

for Internet of Things

研究生： 黃聖翰 撰

中華民國 一零七 年 七 月

ii

摘要

物聯網之快速稽核與違約證明架構

黃聖翰

在這個進入到萬物皆可聯網的時代，隨時隨地都有大量的感測器在傳遞資

料等待分析處理，而蒐集這些資料的組織為了節省存放感測器資料的空間，降

低建構與維護的成本，會選擇租用雲端儲存供應商的儲存空間，目前現有的雲

端儲存服務不外乎為雲端儲存與雲端資料庫，但由於儲存供應商存在內部意外

或外部惡意攻擊的風險，進而導致資料安全上的隱憂，且目前實際商業用的合

約也沒有針對租用者上傳的資料做出保障，而過往理論上的作法雖然對於保障

資料安全與完整性上實現了可供稽核的架構，但在面對大量的物聯網感測器不

斷傳送巨量細碎且需要累計的資料時，不管是針對雲端檔案儲存或雲端資料庫

的稽核架構，都會是一個在效率上的大問題，而對於雲端儲存服務要以何種方

式保存這些持續累計的物聯網裝置資料，值得我們深入探討。

關鍵字：雲端儲存、物聯網、資料稽核、證明違約

iii

誌謝

在此我要先感謝我的指導教授黃冠寰老師，老師不辭勞苦循序漸進的教

導我實用的技巧，並一步步地引領著我反思，建立起對於問題的敏感度，以及

對於問題做出全面性的分析，讓我在這兩年間建立了許多以往沒有學到的知識

與邏輯概念，著實幫助了我許多。在這邊我也想對家人與親密的人表示感謝，

感謝他們在這段期間對我的各種不求回報的支援與指導，也讓我得以完成這兩

年的學業。不用多說，實驗室好夥伴更是互相扶持著一同度過這兩年的歲月，

如安傑學長是我們實驗室的好領導，在論文上更是不遺餘力的指導了我許多不

足的地方，人恩、信德、承翰、一年級離開的宗勳與學弟培鈞也是在課業上幫

助了我許多，這樣相輔相成讓我們彼此間的感情融洽，永遠都不會忘記在實驗

室所發生過的美好時光。非常感謝你們，希望你們即使各自走向不同的道路後

也能在未來一帆風順。

黃聖翰 誌於

國立臺灣師範大學資訊工程所

民國 107 年 7 月

iv

目錄

摘要................................................................................................................................ ii

誌謝............................................................................................................................... iii

目錄............................................................................................................................... iv

附表目錄........................................................................................................................ v

附圖目錄....................................................................................................................... vi

第一章 緒論................................................................................................................ 1

第一節 雲端儲存服務........................................................................................ 1

第二節 雲端儲存一般問題................................................................................ 2

第三節 利用證明違約協定................................................................................ 5

第四節 雲端儲存 IOT 大資料問題 ................................................................... 6

第五節 雲端儲存 IOT 大資料問題之解法 ..................................................... 10

第二章 相關研究探討.............................................................................................. 12

第三章 前文.............................................................................................................. 15

第一節 模數運算.............................................................................................. 15

第二節 Aggregate Hash .................................................................................... 16

第四章 快速檢查及稽核架構.................................................................................. 19

第一節 系統模型.............................................................................................. 19

第二節 方法一：資料插入.............................................................................. 20

第三節 方法一：資料刪除.............................................................................. 23

第四節 方法一：稽核儲存供應商.................................................................. 24

第五節 方法二.................................................................................................. 25

第五章 相關實驗數據.............................................................................................. 28

第六章 結論.............................................................................................................. 35

第七章 參考著作...................................................................................................... 36

v

附表目錄

表 1 各陣列大小稽核時間比較（ms） ............................................................. 29

表 2 各陣列大小空間消耗比較（MB） ........................................................... 29

表 3 8 層 FBHTree 參數 ...................................................................................... 29

表 4 一日所需同步時間(s) ................................................................................. 31

表 5 運算量比較.................................................................................................. 31

表 6 不同累計時間 CSP 消耗空間 ..................................................................... 32

表 7 不同累計時間醫院消耗空間...................................................................... 32

表 8 不同累計時間一般稽核時間...................................................................... 32

表 9 不同累計時間 POV時間 ............................................................................ 33

表 10 實際資料與 POV時所需傳遞 hash pairs 比較(MB) ................................. 33

表 11 實際資料與 POV時所需傳遞 hash pairs 比較(%) .................................... 34

vi

附圖目錄

圖 1 感測器資料與雲端儲存關係圖.................................................................... 2

圖 2 Pure Hashing作法 ......................................................................................... 4

圖 3 Hash Concatenation 作法 .............................................................................. 5

圖 4 使用者更新單筆資料，FBHTree 更新過程 ................................................ 7

圖 5 使用者更新多筆資料，FBHTree 更新過程 ................................................ 8

圖 6 雲端服務商套用 FBHTree 之多位病人感測器資料更新流程 ................... 9

圖 7 樹高為 4 的 FBHTree 與 hash map ............................................................. 14

圖 8 樹高為 9 的 FBHTree Slice ......................................................................... 14

圖 9 Aggregate hash 分群 .................................................................................... 17

圖 10 快速檢查及稽核架構.................................................................................. 20

圖 11 插入時放置 hash pair 示意圖 ..................................................................... 22

圖 12 刪除時移除 hash pair 示意圖 ..................................................................... 23

圖 13 醫院與儲存供應商保存證據示意圖.......................................................... 24

圖 14 方法二架構圖.............................................................................................. 26

圖 15 個別陣列大小與 8 層 FBHTree 效率-空間比較 ....................................... 30

圖 16 POV時間比較（網路） ............................................................................. 34

1

第一章 緒論

第一節 雲端儲存服務

目前主要的雲端儲存服務主要為：雲端檔案儲存（Cloud File Storage）[1]

與雲端資料庫（Cloud Database） [2]。

雲端檔案儲存是一種網路線上儲存的模式，即使用者把資料存放在由第三

方代管的多台虛擬伺服器上。雲端儲存服務供應商（Cloud storage provider）營

運大型的資料中心，若使用者有儲存檔案資料的需求，可透過向雲端儲存服務

供應商購買或租賃儲存空間，來滿足其資料儲存的需求。雲端儲存服務供應商

根據使用者的需求，在後台籌備儲存虛擬化的資源，使用者便可自行使用此虛

擬機器來存放檔案或物件，儲存供應商所提供的服務分布在眾多的不同伺服主

機上，目前主要的儲存供應商有 Google Drive[3]、iCloud[4]、OneDrive[5]等等

。

雲端資料庫是一種執行在雲端運算平台上的資料庫，雲端運算平台提供資

料庫作為一種服務（Database as a service，DBaaS）使用者不需要自己維護資料

庫，由雲端服務提供者負責安裝、維護資料庫實體。資料庫在雲端上支援兩種

資料模型，分為透過結構化查詢語言（Structured Query Language，SQL）[6]存

取資料與不使用 SQL 作為查詢語言（Not Only SQL，NoSQL）[7]存取資料。

2

第二節 雲端儲存一般問題

雲端儲存服務雖然有著節省使用者建置私人儲存硬體的成本的優勢，在應

用場景上，公司可以選擇由雲端儲存來備份伺服器群的資料，醫院也可以透過

雲端儲存大量病人物聯網（IOT）[8]感測器監控資料或者病例，如圖 1。

CSP

Sensors

Sensor data

Sensor data

Sensor data

Organization

Get these data

圖 1 感測器資料與雲端儲存關係圖

在其背後存在著許多隱憂，在目前主流的架構中，使用者將資料上傳至服

務供應商的虛擬伺服器中之後，只能被動相信服務供應商，但諸如伺服器程式

錯誤、伺服器硬體毀損、外部的惡意攻擊甚至內部員工惡意存取修改使用者的

資料等等因素，讓資料安全性蒙上了陰影。

目前的雲端儲存服務的服務層級協定（Service Level Agreement）[9]中僅保

證伺服器的可用性，而會讓使用者安心的安全性條件包含身分驗證（

3

Authentication）、保密性（Confidentiality）、資料的完整性（integrity）以及不

可否認性（Non-repudiation）則一概未保障，其中有些安全性質在使用加密雲

端儲存（Cryptographic cloud storage）[10]來滿足，如身分驗證、保密性以及完

整性，在服務供應商不可信任的狀態之下，加密雲端儲存可以利用加密演算法

及使用者的私密金鑰來簽署數位簽章來保障上傳的資料的完整性以及不可否認

性，但若某些硬體內部毀損使得使用者最新的資料遺失，則可能會導致迴旋攻

擊（Roll-back Attack）[11]的發生，即儲存供應商傳回的使用者簽署過的舊版本

資料。

這邊舉一個簡單的例子：臺大醫院每天總是來來往往不下幾萬名病人，其

中不乏身上配戴多功能穿戴式監控裝置的人，而醫院的醫生們透過從雲端取回

這些裝置所蒐集到的資料，判讀病人身體狀況並且給予適當的配藥，某天儲存

供應商因為硬體意外毀損，偷偷的將資料回復到一星期前，而病人在這星期內

身體狀況有極大的變化，但不知情醫生照往常分析了病人的舊資料，利用自己

的專業調配好適當的藥品交予病人，但最後病人不幸因此身亡，醫生也將莫名

的背負醫療過失的責任。

若一般的使用者面臨到資料竄改或回朔問題，頂多只會造成個人資料上的

損失，但若是醫院存放病人病歷資料的檔案遭到竄改或回朔，很有可能會導致

醫生診斷錯誤，甚至於危害到病人的生命安全，惝若真的發生了醫療事故，在

這醫療糾紛中有沒有機會可以證明醫生的清白，這種人命關天的假設使我們不

得不嚴正面對這個問題。

4

直觀的作法上我們可以很簡單的聯想到對每一份資料都透過雜湊值函數，

如圖 2 得到獨一無二的雜湊值並自行保存，可想而知的是累計越多筆的資料，

對醫院來說要保存的雜湊值的數量也是呈正比成長，確認特定資料的完整性只

能從大量雜湊值中去比對，此作法效率極度不佳。

File

( )

File

File

( )

( )

.

.

.

圖 2 Pure Hashing作法

再更進一步的想法，圖 3 中將那些大量的雜奏值全部連接起來再取一次雜

湊值的方法或許可行，醫院的確減少了需要保存的雜湊值個數，可是面臨到資

料稽核的狀態下，醫院稽核時只能將存儲供應商保存的資料全部下載下來驗算

雜湊值，再大量資料的情況下，雜湊值運算也非常耗時。

5

( ( (

File

( )

File

File

( )

( )

.

.

.

圖 3 Hash Concatenation 作法

第三節 利用證明違約協定

違約證明（Proof of Violation）[12]是指用戶和雲端服務提供商之間可以訂

定一個商業合約，這個服務層級協定 （Service Level Agreement） 合約會依據使

用者所需要的安全性性質訂定價格；若使用者存放於雲端服務供應商的資料遺

失或竄改，則服務提供商必須依據合約賠償使用者。當使用者在使用雲端服務

供應商的服務時，對每一個動作結果皆會產生一個不可否認的密碼學的證據（

cryptographic proof），這密碼學的證據則由使用者與服務供應商分別持有，當

使用者在使用服務上產生爭議時，可以透過這些密碼學證據來稽核（Audit），

證明服務供應商有過失，進而提起違約，反之，服務供應商也可以透過這些密

碼學的證據證明自己沒有過失。

6

[13]利用 Full binary hash tree（FBHTree）來實作對雲端儲存系統的即時稽

核架構如圖 1，使用者上傳的檔案之路徑作為 FBHTree定位葉節點（leaf node）

依據插入該筆資料的雜湊值再依序更新至 root，該架構的優勢在能夠支援 POV

且使用者僅須保存 1 個 root hash 的雜湊值證據。

第四節 雲端儲存 IOT 大資料問題

然而解決了這些資料的安全性問題後，還有一個更大的問題等待著我們處

理，目前現行運作於雲端儲存服務且支援 POV 的架構對於巨量感測器資料稽核

無能為力，過多的資料量都將導致傳遞密碼學證據的資料量太大而使檢驗資料

時間暴漲。

圖 4 為 FBHTree 在更新樹狀結構時的主要步驟，首先使用者上傳 object 至

雲端服務供應商，而雲端服務供應商利用這些 object 產生雜湊值並回傳密碼學

證據，也就是更新 object 的雜湊值後受變動的節點路徑 Slice 給使用者更新，最

後使用者將更新完成後的 Slice 送回給雲端服務供應商，最後雙方透過數位簽章

後的 root hash 確認彼此無誤完成流程，但做一次的更新操作就會產生一條須更

新的 Slice，意味著回傳回來的 Slice數量與更新操作的數量呈正比如圖 5。

7

User

Slice

Update

Agreement

圖 4 使用者更新單筆資料，FBHTree更新過程

8

User

SliceUpdate

Agreement

SliceUpdate

Agreement

SliceUpdate

Agreement. . .

圖 5 使用者更新多筆資料，FBHTree更新過程

9

CSP

Hospital

Patient Group

①Update

②Cryptographyproof

③Agreement

N Users

.

.

.

Object files

圖 6 雲端服務商套用 FBHTree之多位病人感測器資料更新流程

見圖 6，如果我們套用圖 4 的 FBHTree 之方法，若有 N 個 User 且每位 User

傳送 K 的 Object，step 2（圖 6）則需要傳遞 N×K 的 Slices，而每一個包含 PB-

Pairs 的路徑 Slice 之大小約為 3KB[13]。

以剛剛所提到的台大醫院為例子，若其中有 7150個病人（N=7150）且每位

病人配帶著 20 種紀錄不同數據（K=20）的感測器，在 step 1（圖 6）完成所有

的 update 之後，我們會發現在這個例子中一次之 update 動作於為何我們不將這

些資料做打包後在上傳至儲存服務供應商與醫院間將必然產生 14 萬條須更新的

Slice 路徑，這 14 萬條的 Slices 總大小為 439MB，可預見若增大 N 或 K 的數量

則 Slice也會如同圖 5 成長。

整體包含網路傳遞 Slices 最後 Agreement 的同步時間高達 3593.8 秒，我們

可以發現僅僅 14萬筆的資料，其傳遞資料量 overhead高達 75%(439MB/585MB)

。

10

大量的病人身上都配帶著多功能感測器，意即這些病人都會產生大量且細

碎的紀錄資料，這些資料對於判讀病情極其重要且無法承受遭竄改的風險，若

沒有能夠在短時間內有效率的對資料做出稽核，將導致在需要若干資料取回時

的稽核時間過長，以至於沒有辦法針對物聯網裝置的資料儲存做成有利用價值

的商用化系統。

然而這裡可能會有個疑問，為何我們不將這些資料做打包後在上傳至儲存

服務供應商解決這個問題，若將所有人的資料打包成一個，那就會落入先前提

到的直覺做法的缺點，若醫院方對於資料有疑問，那只能請求儲存服務供應商

將那一整包資料回傳回來驗算雜湊值，那資料量遠比剛才提到的 Slices 還要巨

大許多，無法實現快速稽核的目的，那如果我們只將每一個使用者的資料做各

自打包處理呢？在 FBHTree 的結構中，若我們對單一使用者的資料做打包處理

，在稽核階段將無法針對更細部的類別做出稽核，於此同時儲存服務供應商所

傳回來的資料可能大部分都不是醫院方所請求，增加傳遞上的負擔。

第五節 雲端儲存 IOT 大資料問題之解法

使用者將資料上傳於雲端之後，為了避免上面章節所提到的安全性隱憂以

確認我們的資料安全無慮，我們希望使用者能夠放心的使用，即使是小型穿戴

式裝置也能輕鬆應對，且雲端儲存供應商不會因為[14]的作法，對使用者產生

一個密碼學證據就大量消耗儲存空間，達到省空間以及節能的目的。

11

本篇論文將會介紹如何利用最新的研究成果 Aggregate Hash，並基於（

Real-time POV）的即時稽核（Real-time auditing）架構來實作，並以醫院（

Hospital）、病人集團（Patients group）以及雲端儲存供應商（Cloud storage

provider）三者為範本來演示此架構的流程，我們不僅解決了原本應用在醫療資

料的雲端儲存面臨到的問題，預見此種場景下，使用類似處理 Hash pair 作法的

Aggregate Hash 很有可能也會導致稽核時間被拉長，所以在此我們將此快速稽核

架構針對這點融合了 Aggregate Hash 與 FBHTree 各自的優勢，創造出方法二的

做法來解決本節後面所提之 IOT大量資料即時稽核問題。

12

第二章 相關研究探討

由於伺服器分散式儲存技術成熟，導致了雲端儲存的興起，使得使用者甚

至大型機構對於資料的存放除了自身的電腦設備以及自行建立的 NAS 外又多了

一種選擇，但是由於目前市面上提供雲端儲存服務的公司皆未在訂定的協議上

，保證醫院上傳的資料安全性，這對於極大量且具有敏感資料的病歷紀錄更是

一大風險，使得醫院對於節省成本與資料安全取捨的平衡性感到猶豫，以至於

研究者皆想要利用各式的架構或者協議來給這些更需要保護的資料多一分保障

。

在硬體方面，過往對於穿戴式物聯網感測器[15]上的應用仍在起步研究的

狀態，在未注重資料的隱私性與完整性的協定保護下，時常耳聞各種物聯網感

測器資盜遭受竊取甚至於被竄改，這時才發現到廠商在設計時完全沒有考慮資

料安全性疑慮，在[16]中使用 Raspberry-pi 作為中繼的伺服器，來處理眾多感測

器回傳的資料再統籌上傳至儲存服務商，但在資料處理流程中並沒有做如最基

本資料保護的加密的處理，日後這些資料從儲存服務商拿回來時，使用者沒有

辦法對這些資料做完整性檢查的稽核更不用說支援 POV 協定，雖然在沒有任何

保護之下資料傳遞的效率能夠最大化，但這也意即大幅增加傳送過程中遇到的

風險，使用者很有可能在此架構下從儲存服務商拿回來的資料，是已經被惡意

竄改過，但使用者卻沒有任何密碼學證據可以證明。

13

在其他篇論文做法中，[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 的雜湊值證據。

14

1 2

Array subsript

Leaf node ID 0

Tree Height

h1

h2 h3

h4 h5 h6 h7

h15h14h13h12h11h10h9h8

1

2 3

4 5 6

158 9 1412 131110

6

i :Tree node ID

3 4 5 6 7

h1 h2 h3 h4 h5 h6 h7 h8 h9 h10 h11 h12 h13 h14 h15

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15Tree node ID

圖 7 樹高為 4 的 FBHTree 與 hash map

但是反過來說，服務供應商除了要保存使用者的檔案外，必須額外保存其

檔案結構的 FBHTree 樹狀結構以及葉節點的 PB-pair，這點則會造成服務供應商

額外的儲存成本，若使用者更新資料的場景下，服務供應商必須將該更新資料

的路徑先行定位葉節點位置，在將葉節點至根節點中間必須更動的內部節點（

internal node）的 Slice 如圖 8 回傳給使用者自行計算更新後再傳回 Slice 給服務

供應商更新 root hash，若使用者更新大量的 Object 相對的也會產生大量須更新

的 Slice，相關優劣的討論在前一個章節已論述，故在此不在多提。

樹高= 9

:Root Node

:PB-pair

:Internal node

Slice

圖 8 樹高為 9 的 FBHTree Slice

15

第三章 前文

第一節 模數運算

在數學中，群（Group）是由一個集合以及一個二元運算所組成。一個群必

須符合封閉性、結合律、單位元素、以及集合中所有元素都具有反元素等條件[

註:Joseph A. Gallian “Contemporary Abstract Algebra”8th Edition ]。給定兩個整數

a、b，若這兩個整數除以正整數 m所得到的餘數相等，則稱 a，b對於模 m同餘

，記作 a b （mod m）。

即若 P 為質數，hi （0i<n）為 n 個整數， hi< P 且 hi 與 P 互質，且 X 和此

n 個整數的乘積同餘於 P，如下：

X h1h2h3…hk-1hkhk+1…hn-1 （mod P）

在此群中，以下的特性一定成立：

Xhn h1h2h3…hk-1hkhk+1…hn-1hn （mod P）

Xhk-1 h1h2h3…hk-1hk+1…hn-2hn-1 （mod P）

以下舉例：若 P 為 37，且 X 316212938 （mod 37），以下可以計算

出 X 可能的值：（1） 316212938 = 1110816；（2） 1110816 MOD 37 = 2。

所以 X 可以為 2。

我們看範例，X13 31621293813 （mod 37），檢驗看看： （1）

31621293813 = 14440608、14440608 MOD 37 = 26；（2） X13 MOD 37 =

213 MOD 37 = 26。

16

再一個範例，X29-1 31621293829-1 （mod 37），如下檢驗：（1

） 31621293829-1 MOD 37 = 3162138 MOD 37 =9；（2） X29-1 MOD

37= 2 29-1 MOD 37 =2 23 MOD 37=9。

第二節 Aggregate Hash

藉由上述的特性，我們可以加以運用實作雲端 Auditing 及 POV 機制。若有

n個物件存在雲端系統，分別為 O0、O1、…、Ok、…、On-1，我們假定這些物

件內都帶有此物件 hash value 及使用者對此物件 hash value 的電子簽章，這只有

使用者能夠產出。其中，h0 = hash（O0）、h1 = hash（O1） 、h2 = hash（O2）

、…、hn-1 = hash（On-1）。令 X h0h1h2…hn-1 （mod P），我們稱 X 所

有可能值的最小整數，為這 n 個物件的 aggregate hash。要計算出 aggregate hash

很容易，及將這些 hash values 相乘，所得乘積和 P 相除求其餘數，即 aggregate

hash AH= h0h1h2…hn-1 MOD P。則每次新增一物件 Oi，hi=hash（Oi），

新的 aggregate hash AH表示 n+1 個物件，AH = AHhi MOD P。若由這 n 個物

件移除一個物件，新的 aggregate hash AH表示 n-1 個物件，AH = AHhj-1

MOD P。使用者和雲端系統對於儲存於系統物件的互相以電子簽章同意最後的

Aggregate hash，即建立了這些儲存物件的電子證據。

使用者在新增、編刪物件後可以自行運算得出新的 aggregate hash， 雲端系

統也可以得到相同的 aggregate hash。但是在讀取（或下載）物件時，雲端系統

必須將所有物件的 hash values 及使用者的簽章傳送給使用者，使用者先核對這

些簽章是否正確，然後將所有的 hash values 相乘，所得乘積和 P 相除求其餘數

的結果和現在的 aggregate hash 比較是否相同，如果相同表示所得所有物件的

17

hash values 都是正確的。雲端系統無法欺瞞使用者，因為他無法假造使用者的

電子簽章，所以也不可能產生一些 hash values 讓其 aggregate hash 和使用者手上

的 aggregate hash 相同。

但是很明顯的這樣的方法沒有效率，因為每次使用者要讀取（或下載）單

一物件時，雲端系統都必須將所有物件的 hash values 及使用者的簽章傳送給使

用者，如果物件數目十分大時，效率回十分差，比如雲端儲存系統一個帳戶可

以有數萬個檔案，雲端資料庫系統一個 table可以有百萬個 rows。

解決的方法是建立一個協定將物件的 hash values 分群，同一群的物件將他

們的 aggregate hash 存在一個固定的位置。見圖 9，我們將物件分為 k 組，每一

組都有自己的 aggregate hash，分別為 AH0、AH1、…、AHk-1。分組的方法可

以將物件的 hash values 除以 k 取餘數。舉例而言，n 個物件中，O0、O1、…、

Ok、…、On-1，其中，h0 = hash（O0）、h1 = hash（O1） 、h2 = hash（O2）

、…、hn-1 = hash（On-1）。若 hi MOD k = 2，則 hi 分在 AH2 那一組。以此例

而言，若分在第 j 組的有 q 個物件，Oj1、Oj2、…、Ojq。則協定規定，

AHj=hj1hj2…hjq。若 AH 為此 n 個物件的 aggregate hash，則可以證明 AH =

AH0AH1…AHk-1 MOD k。因為每個物件的 hash value 都分配到某一組，所

以 AH0AH1…AHk-1 MOD k = h1h2h3…hk-1hkhk+1…hn-1 MOD k

= AH，即得證。

AH0 AH1 AH2 AHk-1AHk-2AHk-3AHj=hj1 hj2 … hjq MOD P

圖 9 Aggregate hash 分群

18

在使用者的裝置中，只要儲存 k 個 hash values，AH0、AH1、…、AHk-1，

及 aggregate hash。雲端系統除了要儲存此 k 個 hash values 及 aggregate hash，還

要記錄每組有哪些物件的 hash values。舉例，若使用者要自雲端讀取物件 Oj2，

他先算出此物件的 hash values存在第 j組，根據協定雲端系統要傳遞 q個物件的

hash values，hj1、hj2、…、hjq 及 Oj2，給使用者。使用者算出 hj1hj2…hjq

，並比對是否等於自己儲存的 AHj，若相等則進一步檢查 Oj2 內的 tag及簽章及

其 hash value就可以確認是否雲端系統回傳正確的物件。如果通不過稽核，持有

的 AH 可以成為 POV 的電子證據。

19

第四章 快速檢查及稽核架構

在此章節中將會解決在緒論中現今物聯網感測器資料儲存至雲端可能導致

的問題，在此本章將會呈現病人們將自身配戴的感測器裝置，其產生的資料上

傳至雲端儲存供應商時，如何確保上傳的資料的完整性，並且在醫院以及儲存

供應商各自保存該完整性的檢驗證據，以利醫院在對於回傳回來的資料有疑慮

之時，可以快速的檢查以及稽核。

在此架構之下，我們會提出方法一與方法二兩種作法，方法一將病人感測

器的資料，利用 SHA-256 演算法對每一個資料計算出一個 32Bytes 雜湊值，再

使用前文我們所提到由我們實驗室最新研究成果 Aggregate Hash，將這些雜湊值

做分群處理後，保存在陣列中作為之後稽核的證據。

方法二則是解決方法一中面臨大資料量的狀態下，其 POV 時間將會過長，

利用混合 Aggregate Hash 與 FBHTree 的做法解決 POV時間過長問題。

第一節 系統模型

在我們提出的這個架構中將會包含三個實體（entities）：病人集團、醫院

以及雲端儲存供應商，如圖 10：

• 病人集團 : 集團中有著若干個病人，每個病人身上配戴有數量不一的感

測器，而每個病人都會將感測器的資料上傳至雲端儲存供應商保存。

• 醫院 : 負責稽核儲存在供應商資料完整性與取回病人的資料。

• 雲端儲存供應商 : 儲存病人們所上傳的感測器資料。

20

假設每位病人𝑃𝑚身上皆配戴數量不一的感測器，每個感測器皆會在每日結

束後獨自產生數據資料，各自利用 SHA-256 演算法對自身產生的資料取雜湊值

，這邊我們將它稱為 (𝐹𝑖𝑙𝑒 ，其中 (𝐹𝑖𝑙𝑒 = { （𝐷𝑎𝑡𝑎 )| （𝐷𝑎𝑡𝑎 ) }，病

人方完成此一步驟後同時也傳上自身的檔案時間與 ID 完成上傳步驟，而醫院方

及儲存供應商都會收到𝑃𝑚所上傳的 [𝑇𝑖𝑚𝑒𝑚, 𝐼𝐷𝑚, （𝐹𝑖𝑙𝑒） 。

CSP

Hospital

Patient Group

N Patients

.

.

Sensor data

.

.

𝑃

𝑃

𝑃𝑚

𝑃 Data fingerprint

AgreementCryptographyproof

圖 10 快速檢查及稽核架構

第二節 方法一：資料插入

此節將會介紹病人們將資料上傳至儲存供應商的同時，醫院與供應商各自

利用 Aggregate Hash 建立稽核證據的詳細流程。

21

醫院及儲存供應商得到[𝑇𝑖𝑚𝑒𝑚, 𝐼𝐷𝑚, （𝐹𝑖𝑙𝑒）]，同時也會計算𝑇𝑖𝑚𝑒𝑚以及

𝐼𝐷𝑚作 Concatenation 的雜奏值得到 （𝑇𝑖𝑚𝑒, 𝐼𝐷），且利用此雜湊值做分群處理

，在我們架構中決定分群的方法為 （𝑇𝑖𝑚𝑒, 𝐼𝐷）取 Module N，其中 N 為預設

Aggregate Hash 的總群數，意即陣列的大小，決定完該雜湊值隸屬的群，也就是

該陣列的位置 k 後，將時間與 ID 的雜湊值以及檔案的雜湊值配對（hash 𝑝𝑎𝑖𝑟）

： (𝑇𝑖𝑚𝑒, 𝐼𝐷 ， (𝐹𝑖𝑙𝑒 存入該位置 k 下的 Hash map 如圖 11。

若是該陣列未被插入過，則每個陣列位置的 Aggregate Hash 𝐴𝐻存放初始值

為 1，插入 Hash map 後我們會計算出該位置 k 由 （𝑇𝑖𝑚𝑒, 𝐼𝐷）與 (𝐹𝑖𝑙𝑒 作

Concatenation後的雜湊值 𝑖，並乘以該位置 k下舊的𝐴𝐻𝑘後對該值做Module P的

運算，以得到新的𝐴𝐻𝑘′即完成證據的更新，其中我們會把 P設成一個 257bit的大

質數，以保證雜湊值不為 P的倍數，這會使得計算出來的結果是 0，導致先前的

保存的 Aggregate hash 被吸收掉。

𝒉𝒊 = 𝒉 𝒉（𝑻𝒊𝒎𝒆, 𝑰𝑫），𝒉（𝑭𝒊𝒍𝒆）

𝑨𝑯𝒌′ = （𝑨𝑯𝒌 × 𝒉𝒊 ）𝑴𝒐𝒅 𝑷

在此醫院在 POV 的證據保存上因為群的交換律性質所致，防止儲存服務商

與醫院方在 Agreement 時完成最終的𝐴𝐻確認，而實際上兩者所保存的陣列中的

值𝑨𝑯𝒌相異的狀況，但也僅僅只需儲存一個一維陣列即可，而儲存供應商除了

一個陣列外也僅需要保存陣列下的 hash map，降低服務供應商因為[13]方法保存

過大的樹狀結構額外產生的成本，相對地能同時間服務更多病人上傳資料，相

關的比較實驗數據會在下個章節提供。

22

𝑨𝑯 … 𝐴𝐻𝑘′ … 𝑨𝑯 𝐴𝐻′

𝑖 = ( , (𝐹𝑖𝑙𝑒

= 𝑒 𝑡 𝑎 pair 1 = 𝑒 𝑡 𝑎 pair 2

.

.

.

圖 11 插入時放置 hash pair 示意圖

23

第三節 方法一：資料刪除

在資料刪除上的做法其實與插入很相似，首先醫院將欲刪除之時間與病人

ID 透過雜湊值函式重新算回 （𝑇𝑖𝑚𝑒, 𝐼𝐷），一樣透過模數運算確認

（𝑇𝑖𝑚𝑒, 𝐼𝐷）在陣列上的位置 k 後，要求儲存供應商將其保存的陣列位置 k 下

的 hash map 回傳回來，由醫院一一尋找存放 （𝐹𝑖𝑙𝑒）欄位中等於欲刪除之

（𝑇𝑖𝑚𝑒, 𝐼𝐷）雜湊值，尋找完成即重新計算 𝑖並求其與大質數 P 的模反元素

𝑖 ，並乘以該位置 k 下舊的𝐴𝐻𝑘後對該值做 Module P 的運算如圖 12，以得到

新的𝐴𝐻𝑘′′即完成證據的更新。

醫院再將該 𝑖 回傳使儲存供應商更新陣列位置 k 的𝐴𝐻𝑘成𝐴𝐻𝑘

′′，並移除該

hash pair，即完成整體資料刪除的證據更新。

在移除資料的證據上，由於證據更新僅需要運算模反元素以及一個乘法運

算，使得證據更新速度遠快於需要將樹狀結構的 Slice 節點上所有雜湊值更新的

[13]，其比較數據將於下一個章節提供。

𝑨𝑯𝒌′′ = （𝑨𝑯𝒌 × 𝒉𝒊

）𝑴𝒐𝒅 𝑷

𝑒𝑚 𝑒

𝑒 𝑡 𝑎 pair 1 𝑒 𝑡 𝑎 pair 2

.

.

.

𝑨𝑯 … 𝐴𝐻 … 𝑨𝑯 𝐴𝐻′′

圖 12 刪除時移除 hash pair 示意圖

24

第四節 方法一：稽核儲存供應商

這 邊 我 們 假 設 欲 稽 核 某 時 某 病 人 的 資 料 是 否 正 確 ， 令 𝑖 =

（𝑇𝑖𝑚𝑒, 𝐼𝐷）， （𝐹𝑖𝑙𝑒） ，且 （𝑇𝑖𝑚𝑒, 𝐼𝐷） Module P = K，且在陣列位置

K下已經存有 m 個檔案，意即 m 個 hash pair （ ~ 𝑚）

首先比對儲存供應商回傳的陣列中每個位置的 Aggregate Hash 𝐴𝐻是否與醫

院所保存的皆相等如圖 13，若否則證明儲存供應商違反合約規定，若相同則進

入第二階段稽核。

•

𝑨𝑯

𝑨𝑯 … 𝑨𝑯 … 𝑨𝑯

•

𝑨𝑯

𝑨𝑯 … 𝑨𝑯 … 𝑨𝑯

( , (𝐹𝑖𝑙𝑒

圖 13 醫院與儲存供應商保存證據示意圖

進入第二階段後，醫院要求儲存供應商回傳所有陣列位置 K 下 hash map 中

的 Hash pair :（ （𝑇𝑖𝑚𝑒, 𝐼𝐷）𝑗， （𝐹𝑖𝑙𝑒）

𝑗 ） ，醫院接收到後一一驗算

（𝑇𝑖𝑚𝑒, 𝐼𝐷）𝑗 Modul 𝑁是否等於 K，確認是否皆定位在陣列位置 K，確認驗

算完畢後醫院再來一一驗算 𝑗 = （ （𝑇𝑖𝑚𝑒, 𝐼𝐷）𝑗， （𝐹𝑖𝑙𝑒）

𝑗 ），最後醫院

25

計算( × × × 𝑚 × 𝑚 𝑀 𝑑𝑢𝑙𝑒 𝑃，其結果與醫院自身保存的𝐴𝐻𝑘相符

，即完成整個稽核流程，反之則表示，其中儲存供應商違反合約規定。

j = 1,2, ,

醫院為了確保存放於儲存供應商的病人資料不因任何意外或者惡意竄改而

完整性被破壞，因此能夠快速在大量檔案下達到快速稽核的目的在我們的架構

中是最為重要的一部分，若稽核結果出現落差，則可判定儲存供應商違反 POV

，醫院可以已訂定合約的儲存服務商提出賠償要求。

第五節 方法二

在上述的作法中，我們利用了 Aggregate Hash 實現了以往[13]所使用的

FBHTree 中相同的功能，卻用更簡潔快速的做法來實現快速稽核，但是在此我

們有了新的疑慮，在源源不斷的感測器監測資料流入的狀態之下，累積起來的

資料筆數數以百萬甚至千萬計，若醫院稽核時發現與儲存服務商所保存的陣列

證據不一致而必須進行 POV 時，醫院方勢必只能要求儲存服務商將有疑慮的陣

列位置下所有 Hash pairs 回傳自行驗算。

在[13]的實驗中我們觀察到 FBHTree 結構若塞入極大量的資料，將會有兩

種解決方法，第一種我們可以讓他自動加大層數以容納更多筆資料的同時其

PB-pairs碰撞不會隨之升高，但這做法的有個明顯的缺點，其稽核時間將會大幅

提升，而儲存服務商所保存的結構大小也會隨之暴漲，而第二種作法則是固定

leaf node數量不會隨著資料筆數而作變動，但很明顯的 leaf node下的 PB-pairs碰

撞也會大幅提升，這也導致處理 PB-pairs 碰撞時間與整體稽核時間大幅拉長。

26

預見此種場景下，使用類似處理 Hash pair 作法的 Aggregate Hash 必須將所

有的 Hash pairs 回傳回來，其 POV時間最大關聯就是在回傳 Hash pairs，所以在

此我們將此快速稽核架構針對這點融合了 Aggregate Hash 與 FBHTree 各自的優

勢，創造出圖 14 方法二的做法來解決本節開頭所提之極大量資料即時 POV 問

題。

首先我們將原始沒有限制資料筆數的 Aggregate Hash 陣列，轉變成以固定

天數間隔內之資料量的多個 Aggregate Hash 陣列，例如：一個陣列只保存一周

七天間隔的資料，下個間隔的資料保存在下個陣列以此類推，這間接限制每個

陣列插入筆數的大小，避免方法一插入太多筆資料導致大量 Hash pairs的碰撞的

傳遞與計算問題。

…

…

: Aggregate hash array

: FBHTree leaf node

: FBHTree root node

圖 14 方法二架構圖

其中 leaf node 存每個間隔醫院與儲存服務商雙方簽章過的𝐴𝐻與𝐴𝐻的最新

版 本 號 （ 𝐴𝐻, 𝑛 ） ， 依 序 從 最 左 側 的 leaf node 存 至 最 右 側 （

27

𝐴𝐻 , 𝐴𝐻 , 𝐴𝐻3, 𝐴𝐻4,…），將最終運算的 root hash 與更新的版本號再由醫院與儲

存服務商雙方簽章（ 𝑡 ℎ𝑎 ℎ, 𝑛），此做法與最初的方法比較，儲存服務商

必須保存每個間隔的陣列與每個陣列位置下的 hash pairs 及（𝐴𝐻𝑖, 𝑛）外，還要

額外存 FBHTree 結構的一維陣列及（ 𝑡 ℎ𝑎 ℎ, 𝑛），但是醫院從原本需要保

存陣列變成僅需要保存 （ 𝑡 ℎ𝑎 ℎ, 𝑛）與 （𝐴𝐻𝑖, 𝑛）即可，減少所需的儲

存空間。

在POV時，首先利用（ 𝑡 ℎ𝑎 ℎ, 𝑛）確認版本號後，醫院推算出欲POV

的（𝑡𝑖𝑚𝑒, 𝐼𝐷）所對應的周期間隔，使用自己保存該週期的（𝐴𝐻𝑖 , 𝑛） POV 上

層的 FBHTree，由儲存服務商傳遞 Slice 由兩方各自推算 root hash 是否相等後完

成第一階段 POV，第二階段進入該週期間格的 Aggregate Hash 陣列 POV，醫院

方將所有自雲端服務商接收到的所有 hash pairs 並做運算重建陣列，最後對照醫

院方自已所持有的陣列內容。。

融合了 FBHTree 醫院方僅需保存少量資料與 Aggregate Hash 資料插入刪除

與 POV 速度的優點，這使我們可以利用此方法完美的解決掉極大量資料下兩者

所遇到 POV效能上的瓶頸。

28

第五章 相關實驗數據

在本章節，我們會利用實驗來說明在上一個章節所提到整體系統架構的數

據，實現整體快速稽核架構的程式語言為 Java，在此實驗會分為單一電腦測試

以及相同網路區段與相異網路區段的電腦分別扮演儲存供應商以及醫院，扮演

同網段儲存供應商的電腦作業系統為 Windows 10，處理器為 Intel（R） Core（

TM） i7-7700 CPU @3.60GHz，記憶體為 16GB DDR4；扮演異網段儲存供應商

的電腦為 acer Aspire VN7，作業系統為 Windows 10，處理器為 Intel（R） Core

（TM） i5-6300HQ CPU @2.30GHz，記憶體為 16GB DDR4；而醫院方的電腦為

acer Aspire V5，作業系統為 Windows 10，處理器為 Intel（R） Core（TM） i5-

4200U CPU @ 1.6GHz，記憶體為 12GB DDR3。

而測試的檔案為 4KB 純文字檔以模擬感測器所產生的資料，假設每日產生

14 萬筆資料並以每周為一個週期，而這一周將產生 100 萬筆資料，比較一、方

法二與 FBHTree 這三種方法之一日/一周/一月/三月/六月/一年累計資料量下各種

參數。

在上一章節有提到在面臨極大量的資料下，即使是操作效率非常高

Aggregate hash，仍然有可能因為密碼學證據並不符合手上持有的，意即稽核時

發生錯誤而必須進行 POV，所以我們提出了一個結合Aggregate hash與 FBHTree

優點的作法，但由於這種作法仍會導致儲存服務商所需保存證據的空間增大，

所以首先先針對各種不同大小的 Aggregate hash陣列找出空間與效率平衡間最佳

的選擇（表 1、表 2），再來必須為方法二選定適當的 FBHTree大小，在一年的

假設下選擇使用 leaf node 數量為 128 的 8 層 FBHTree 之參數（表 3），在結合

大小為𝟐 的陣列與 8層 FBHTree下，其網路傳輸稽核的效率與空間消耗上剛好

29

處在平衡點（見圖 15），分析後主要原因為在過大的陣列上雖然碰撞率較低，

不過也因此消耗了大量的空間儲存此陣列，若以方法二儲存若干個陣列此種影

響也會隨之放大，另外一方面過小的陣列則將導致碰撞率大幅提高，稽核時必

須要大量的 hash pairs 傳送回醫院而傳送時間又因網路節點延遲影響，使得整體

集合時間大幅拉長，這也是我們決定以這個參數作為方法一與方法二 Aggregate

hash 陣列大小的參照值。

表 1 各陣列大小稽核時間比較（ms）

𝟐𝟑 𝟐𝟕 𝟐 𝟐 𝟓 𝟐 𝟗

稽核 172.72 25.62 2.84 0.0057 0.0026

Hash pairs

傳送 1870 168 39.42 26.97 24.93

表 2 各陣列大小空間消耗比較（MB）

𝟐𝟑 𝟐𝟕 𝟐 𝟐 𝟓 𝟐 𝟗

Hospital

所需空間 0.0007 0.0087 0.142 2.16 31.45

CSP

所需空間 132.5 132.5 132.8 133.7 149.5

表 3 8 層 FBHTree 參數

Space cost（KB） # of leaf node POV

without internet（ms）

POV

with internet（ms）

16.2 128 0.12 19.41

30

0

500

1000

1500

2000

2500

130 132 134 136 138 140 142 144 146 148 150 152

CSP WITH HASH PAIRS TRANSATION

𝟐

𝟐3

𝟐

𝟐 𝟐

X 軸 : CSP 消耗空間(MB)

Y 軸 : POV時間(ms)

圖 15 個別陣列大小與 8 層 FBHTree 效率-空間比較

再來我們將在同樣假設條件下，首先比較方法一、方法二與 FBHTree 三種

方法之一日同步時間（表 4）、同步時各種運算量的比較（表 5），我們可以發現

20 層的 FBHTree 在同步時其花費時將相對於方法一與方法二高出許多，主因是

每同步完成一個資料必須由雲端服務商回傳 Slice 給醫院運算，最後在雙方認同

這結果這階段花費時間過多，且進行雜湊值運算更新樹狀結構所需花費的運算

量也較高，而方法一跟方法二皆使用的𝟐 陣列大小的 Aggregate hash，以至於

兩者間同步都是維持相當優異的表現。

表 6、表 7則是呈現了三者在雲端服務商與醫院方所需保存的密碼學證據量

，FBHTree 因樹狀結構必須保存內部節點，導致其消耗的空間較方法一與方法

二大，而我們先前所選出的𝟐 陣列大小使得方法一與方法二大幅減少了雙方在

31

保存陣列上所需要的空間。

而最後的表 8 與表 9 則是呈現了三者在稽核與 POV 時所需的時間消耗，我

們可以發現 FBHTree 在這方面相當突出，因其稽核與 POV 時僅需要驗證一條

Slice 與 root hash，而方法一則是會因為一個陣列中塞入太多筆資料，導致於碰

撞過高且必須回傳的 hash pairs 過多，使得稽核與 POV 時間逐漸增長，方法二

將陣列大小利用固定周期作切割，使得不管是一般稽核或者是更消耗時間的

POV都能穩定的維持在常數，不會因為資料筆數的增長而成長。

表 4 一日所需同步時間(s)

時間

[13] 3593

Method 1 19

Method 2 19

表 5 運算量比較

Hash 乘除法 模數運算

[13] 3,289,000 2,717,000 143,000

Method 1 572,000 286,000 429,000

Method 2 572,011 286,007 429,001

32

表 6 不同累計時間 CSP 消耗空間

一日 一周 一月 三月 六月 一年

[13] 52MB 190MB 950MB 2,850MB 5,700MB 11,400MB

Method 1 18MB 132MB 663MB 1,978MB 3,958MB 6,859MB

Method 2 18MB 132MB 664MB 1,980MB 3,960MB 6,864MB

表 7 不同累計時間醫院消耗空間

一日 一周 一月 三月 六月 一年

[13] 32Byte 32Byte 32Byte 32Byte 32Byte 32Byte

Method 1 0.142MB 0.142MB 0.142MB 0.142MB 0.142MB 0.142MB

Method 2 0.143MB 0.143MB 0.147MB 0.157MB 0.162MB 0.192MB

表 8 不同累計時間一般稽核時間

一日 一周 一月 三月 六月 一年

[13] 25.93ms 25.93ms 25.93ms 25.93ms 25.93ms 25.93ms

Method 1 8.47ms 43.2ms 131.8ms 286.1ms 457.7ms 793.1ms

Method 2 27.88ms 61.67ms 61.67ms 61.67ms 61.67ms 61.67ms

33

表 9 不同累計時間 POV時間

一日 一周 一月 三月 六月 一年

[13] 25.93ms 25.93ms 25.93ms 25.93ms 25.93ms 25.93ms

Method 1 27.81s 87.57s 266.3 596.5s 936.5s 1403s

Method 2 27.81s 87.57s 87.57s 87.57s 87.57s 87.57s

最後我們在特別針對方法一與方法二在傳遞證據時的 overhead 做比較如圖

16，在此將不同累計時間周期的實際保存資料做比對如表 10，我們可以發現方

法一在存入資料筆數越多的狀態下，在 POV 時所需回傳的 hash pairs 也會增長

，但是整體的 overhead 仍然是維持在 3.2%左右如表 11，而方法二得力於週期切

割使得不管資料累計筆數如何增長，皆能保持不增長且維持在常數狀態，這也

是讓方法二在資料筆數越多，整體 overhead 反而呈現下降的主因。

表 10 實際資料與 POV時所需傳遞 hash pairs 比較(MB)

一日 一周 一月 三月 六月 一年

實際資料大小 585 4,100 20,500 61,501 123,003 213,790

Method 1 18 132 663 1,978 3,958 6,859

Method 2 18 132 132 132 132 132

34

表 11 實際資料與 POV時所需傳遞 hash pairs 比較(%)

一日 一周 一月 三月 六月 一年

Method 1 3.076 3.219 3.234 3.216 3.217 3.208

Method 2 3.076 3.219 0.643 0.214 0.107 0.061

0

200

400

600

800

1000

1200

1400

1600

1800

2000

一日 一周 一月 三月 六月 一年

POV時間(網路)

Method 1 Method 2

X 軸 : 累計資料時間

Y 軸 : POV時間(s)

圖 16 POV時間比較（網路）

35

第六章 結論

在這個雲端儲存逐漸佔據我們生活周遭的世界，使得我們除了原本自行儲

存或者搭建分散式伺服器的選擇外，還可以租用適當的以量計價雲端儲存服務

來節省硬體建構、維護的成本，但是其背後隱藏的安全問題值得我們深思，現

今的儲存供應商所訂定的服務層級協議（Service Level Agreement）仍然未能保

證這些檔案的安全性等等，若發生疑似竄改、替換甚至回溯檔案，租用者也沒

有適當的證據可以去釐清責任的歸屬，尤其是需要保存大量病患重要資料的醫

療機構，任何非意願的改動都有可能成為危害病人生命的工具。

一般狀態下若我們需要保障這些資料的安全，可以利用支援 POV 的協定的

架構處理，如前面所提到的 FBHTree。

在 IOT 裝置所產出資料的特性，我們會發現這些資料是不斷的疊加累計上

去，而且這些資料拆分來看十分細碎，使用者或是組織想要從中於 CSP 取得特

定的資料又須確保其資料的完整，在目前現有的架構中是無法應對的。

即使我們發展出新的 POV 架構 : Aggregate Hash ，的確在各方面上都勝過

過往做法的 FBHTree，但依然對於 IOT巨量資料上的特性仍有缺陷。

以至於我們再提出混合了 Aggregate Hash 與 FBHTree 兩者優點的新架構，

增加密碼學證據的同時，利用區間對那些不斷累計的資料做出多次切割，解決

了以往不可能兼具資料 POV與超大量細碎資料之問題。

36

第七章 參考著作

[1] Cloud storage. from https://aws.amazon.com/tw/what-is-cloud-file-storage/

[2] Cloud database. from http://en.wikipedia.org/wiki/Cloud_database

[3] Google Drive. from https://www.google.com/drive/

[4] iCloud. from https://www.icloud.com

[5] OneDrive. from https://www.onedrive.com

[6] SQL. from http://en.wikipedia.org/wiki/SQL

[7] NoSQL. from http://en.wikipedia.org/wiki/NoSQL

[8] IoT. from https://en.wikipedia.org/wiki/Internet_of_things

[9] Service Level Agreement. from https://en.wikipedia.org/wiki/Service-

level_agreement

[10] Seny Kamara and Kristin Lauter. (2010). Cryptographic Cloud Storage. Financial

Cryptography Workshops, pp. 136-149.

[11] J. Feng, Y. Chen, D. Summerville, W.S. Ku, and Z. Su. (2011). Enhancing cloud

storage security against roll-back attacks with a new fair multi-party non-

repudiation protocol. IEEE Consumer Communications and Networking

Conference (CCNC), pp.521-522

[12] Gwan-Hwan Hwang, Jenn-Zjone Peng, and Wei-Sian Huang. (2013). A Mutual

Nonrepudiation Protocol for Cloud Storage with Interchangeable Accesses of a

Single Account from Multiple Devices. 12th IEEE International Conference on

Trust, Security and Privacy in Computing and Communications (IEEE TrustCom-

2013).

37

[13] Gwan-Hwan Hwang, Hung-Fu Chen. (2016). Efficient Real-time Auditing and

Proof of Violation for Cloud Storage Systems. 9th IEEE International Conference

on Cloud Computing.

[14] Swaleha Shaikh, Vidya Chitre. (2017). Healthcare Monitoring System Using IoT.

International Conference on Trends in Electronics and Informatics (ICEI).

[15] K. Jaiswal,S. Sobhanayak,B.K. Mohanta,D. Jena (2017). IoT-Cloud based

framework for patient’s data collection in smart healthcare system using

Raspberry-pi. International Conference on Electrical and Computing

Technologies and Applications (ICECTA).

[16] G. Ateniese, R. C. Burns, R. Curtmola, J. Herring, L. Kissner, Z. N. J. Peterson,

and D. X. Song. (2007). Provable data possession at untrusted stores. ACM

Conference on Computer and Communications Security, pp. 598–609

[17] G. Ateniese, R. D. Pietro, L. V. Mancini, and G. Tsudik. (2008). Scalable and

efficient provable data possession. Proceedings of the International Conference

on Security and Privacy in Communication Netowrks, pp. 1–10

[18] Jianfeng Wang, Xiaofeng Chen, Xinyi Huang, Yang Xiang. (2015). Verifiable

Auditing for Outsourced Database in Cloud Computing. IEEE TRANSACTIONS

ON COMPUTERS, VOL. 64, NO. 11

[19] Merkle hash tree. from https://en.wikipedia.org/wiki/Merkle_tree

[20] Bloom filter. from https://en.wikipedia.org/wiki/Bloom_filter

38

國立臺灣師範大學

資

訊

工

程

研

究

所 碩（博）士論文

物聯網之快速稽核與違約證明架構

黃聖翰

撰

107

7

（提送年月）