4. 系統分析
4.4. 安全性分析
4.4 中我們已對系統本身在空間與時間上的效能做出評估，在本章節將會進 一步對系統的安全性進行分析，檔案本身在未加密的情況下的安全性、或是某 些檔案內容較容易遭到破解等問題。
4.4.1. Key Blocks組合數對安全性的影響
在前文所提到系統架構中，假設一個 Chunk 包含 k 塊 Input Symbols，則 Key Manager 將以(k-1)份 Encoding Symbols 做為 Public Blocks，剩下的一份為 Key Blocks。然而這一塊 Key Blocks，就破解難度而言並不高。由於系統在運算時都 是於有限域內，若破解者任意產生一組數據當作偽造的編碼區塊，則只要注意 係數w 的部份不要與(k-1)份的 Public Blocks 相同，接下來就只要猜測m w 的部m 份，最多只要猜測 216可能性就能破解出答案，假設破解者能夠取得 Chunk 的
圖 4-13 32-bit LT Code 解碼所需時間比較
Public Blocks 部分，則破解難度相當低。
為了彌補這個缺點，系統修正為(k-m)份 Public Blocks，相當於 Key Blocks 為 m 份，如此一來利用猜測來破解 Chunk 的難度就變高了，圖 4-14 m 與破解 所需嘗試組合數的關係圖的 Chunk Size 固定為 1024 bits，X 軸為 m 的數目，Y 軸為破解 Chunk 需要嘗試的組合數(10n種)。從圖中可以看出破解難度隨著 m 的 增加而呈線性成長，除此之外破解難度也會因為 Field Size 的不同而提升，在圖 中的兩條曲線分別代表 Field Size = 16 bits 與 Field Size = 32 bits，以傳統非對稱 RSA 加密演算法來說，可靠的金鑰長度為 1024 bits，換算成 Key Blocks 則至少 需 m=64(Field Size = 16 bits 時)或 m=32(Field Size = 32 bits 時)，但這樣就相當於 Key Blocks 佔了整個 Chunk 的 100%，並不符合實際。一般來說我們能接受 Key Blocks 在整個 Chunk 中佔的比例在 20%以下，因此當 k=64 時，m=12，金鑰長 度為 192 bits，比 RSA 少了 832 bits，在安全性上遜色不少，雖然可利用增加 Chunk Size 的方法來提高金鑰長度，但其中所帶來的額外時間與空間成本仍須衡量。
圖 4-14 m 與破解所需嘗試組合數的關係圖
另一方面，提升 m 雖然可增加安全性，但 m 的提升代表 Key Blocks 在 Chunk 中佔的比例也越大，這也表示 Key Manager 需要傳送更多的資料給接收方，或者 使用者必須儲存更多資料在自己的隨身儲存裝置，因此如何拿捏 m 的數目也是 本系統的議題之一。
4.4.2. Key Blocks外洩造成的影響
上一節已知 m 的數目會影響到 Key Blocks 遭破解的難度，而安全性也會隨 之提昇，但如果只是單純的提高 m，安全性未必就會一直提高。舉例來說，如 果有心人士刻意蒐集不同的 Key Blocks，若蒐集份數達到復原檔案的門檻(k 塊)，那麼他就有可能成功竊取檔案，這正好與 404.4.1 的議題形成一個 tradeoff，
因此為了衡量一個適當的 m 值，必須顯示出這兩者之間的取捨。
圖 4-15 m 對於安全性的影響(Field Size = 16 bits)是基於圖 Field Size = 16
bits 的資料再加上另一條曲線，代表了 m 與需要蒐集的 Key Blocks 數目之間的 圖 4-15 m 對於安全性的影響(Field Size = 16 bits)
關係，隨著 m 的提高，將會大幅降低需要蒐集的 Key Blocks 數目，畢竟如果 Key Blocks 在 Chunk 中的比例佔越大，就代表只要蒐集越少的金鑰就能達到復原門 檻，而從圖中可以觀察到兩條曲線之間的平衡點約在 m=8 的地方。
由於 16-bit 與 32-bit 會影響到 k 的大小，因此必須分開討論。圖 4-16 m 對 於安全性的影響(Field Size = 32 bits)為 Field Size = 32 bits 的情況，此處兩條曲線 的交會約在 m=7 的地方。由這兩張圖可以得知雖然 16-bit 與 32-bit 得到的 k 不 同，但基本上適當的 m 值都差不多。
4.4.3. Chunk Size對安全性的影響
4.4.1 與 4.4.2 我們針對 Key Blocks 的安全性以及探討 m 的適合值，然而除 了 m 以外，Chunk Size 也同樣會影響 Key Blocks 的安全性。
在 4.4.2 已舉出若 Key Blocks 遭攻擊者蒐集至復原門檻，則該 Chunk 有遭破 解的可能性，因此 m 的提高帶來了好處與壞處，但假設 m 為定值，提高 Chunk Size
圖 4-16 m 對於安全性的影響(Field Size = 32 bits)
會令 k 也一同增加，同時提高復原門檻達到增加安全性的效果。圖 4-17 Chunk Size 對於安全性的影響顯示了 Chunk Size 的增加對安全性的影響；X 軸為 Chunk Size，Y 軸為破解此 Chunk 所需要蒐集的 Key Blocks 份數，固定因素為 m = 8(16-bit)與 m = 7(32-bit)，從圖中可以看到安全性隨著 Chunk Size 的提高而線性 成長，雖然 Field Size = 32 bits 的曲線因為 k 較小的原因故成長較緩，但我們依 然可以知道 Chunk Size 的提高對安全性是有幫助的。
然而，Chunk Size 的提升會讓時間與空間成本一齊上升，速度最慢的 LC Code 在 Chunk Size = 1024 bits 與 8192bits 上甚至差了七、八倍左右，反觀 LT Code 便上升的不是那麼明顯。
4.4.4. 檔案中的特殊Chunk造成的影響
利用本系統對檔案進行編碼前會先將檔案切成許多 Chunk，每個 Chunk 都 代表了一部分的檔案內容，然而有時會因為某些檔案內容的特性，導致安全性
圖 4-17 Chunk Size 對於安全性的影響
受到影響，本章節會討論那些特殊檔案內容所造成的情況與因應對策。
1) Zero Chunk：某些檔案內容可能有一部分皆為 0，因此在切成 Chunk 時會 產生內容全部是 0 的 Chunk，當 Zero Chunk 出現時不管利用何種 Erasure Code 所產生的 Encoding Symbols 皆為 0，使得 Chunk 內容非常容易被推測出來；若 要改善這點可以先對檔案內容進行 Hash，如此一來便可避免 Zero Chunk 的產生。
2) Constant Chunk：與 Zero Chunk 類似，但其內容皆為一致的常數，利用 Constant Chunk 產生的 Encoding Symbols 與 Zero Chunk 相較起來雖然比較不容 易發覺，但如果利用的是 LT Code 則一目了然(產生 Symbols 皆為 0)；改善方法 依然可以先利用 Hash Function 來避免產生。