第三章系統架構與資料流

文件元數據

白皮書版本

v1.0

最後更新

2026-01-14

3.1 組成部分

• Client: 將檔案分割、加密/解密並管理 URL 片段中的 CEK。
• API/Edge: 發行並驗證範圍令牌；提供清單和密文區塊。
• 物件儲存： 儲存加密的區塊和清單；對於明文機密性而言，被視為不可信。
• 國營商店： 使用最少的元資料追蹤傳輸狀態（上傳進度、過期、撤銷）。

3.2 資料對象

• Manifest: 取得和組裝區塊所需的公共參數（加密版本、區塊大小/計數、映射）；不得包含 CEK。
• Chunk: 加密的檔案片段（密文）加上最小的元資料（長度/etag），由（transferId，fileId，chunkIndex）定址。
• State: 用於授權、TTL、撤銷和可復原性的伺服器端記錄。

3.3 上傳流程

1. 客戶端創建傳輸並接收綁定到的短暫的、有範圍的上傳令牌 transferId.
2. 客戶端在本機上產生每個檔案的 CEK，將檔案分割為固定大小的區塊，並使用 AEAD 加密每個區塊。
3. 客戶端並行上傳密文區塊；每個區塊的重試都是冪等的。
4. 客戶端上傳清單（僅限公共參數）。當所需零件存在時，伺服器將傳輸標記為就緒。

3.4 下載流程

1. 收件人開啟共享連結。 URL 片段（CEK 資料）保留在瀏覽器中，不會傳送到伺服器。
2. 客戶端使用範圍內的下載令牌取得清單並確定區塊計劃。
3. 用戶端下載密文區塊（可選並行），驗證 AEAD 驗證，然後組裝明文檔案。
4. 發生故障時，客戶端透過僅請求遺失的區塊來恢復；完整性失敗必須失敗關閉。

3.5 寄件者管理和審核流程

• 寄件者使用長期登入令牌（儲存在客戶端上）進行身份驗證以進行管理操作。
• 管理 API 允許列出轉帳、檢查交付證據以及撤銷/刪除轉帳。
• 審核資料被設計為僅對發送者可見；預設情況下，它不會向收件者公開。

3.6 可見性和最小化

• 伺服器和儲存只處理密文和必要的公共參數；如果沒有 CEK，他們無法解密內容。
• 日誌和分析應最小化，且不得包含 URL 片段或 CEK 資料。
• 元資料收集應該有目的（交付證據、濫用預防和操作可靠性）。