「保險庫」即將上線：以端對端加密守護你的私密檔案

我們很高興地告訴大家，PikPak 全新的安全功能：保險庫（Vault），目前已進入系統測試階段，並將逐步從行動端 App 開始進行灰度推出。

這不只是一個用來「上鎖」的資料夾。不同於大多數雲端硬碟產品中的保險箱、私密空間或類似功能，PikPak 保險庫除了具備自動鎖定、生物辨識驗證等本機安全保護之外，更重要的是，我們為它設計了一套全新的端對端加密機制，也就是常被稱為零知識加密儲存（Zero-Knowledge Encrypted Storage）的安全架構。

這代表你的加密金鑰只會由你自己掌握。即使是 PikPak，也無法直接讀取、解密或查看你存放在保險庫中的檔案內容。對於希望保存高度私密資料、重要文件或個人珍藏的使用者來說，這是我們目前能提供的最高等級安全保護之一。

為了實現這項功能，我們已經投入了數個月時間，反覆研究端對端加密、金鑰管理、多裝置同步與使用體驗之間的平衡。我們仔細斟酌每一個技術選型，並針對安全性、可靠性與易用性進行了完整的設計與研發。對雲端硬碟來說，真正的挑戰不只是「把檔案加密」，而是加密之後仍然要支援同步、分享、轉存、播放和斷點續傳。

接下來，我們想把這套設計拆開來看。先從最關鍵的一步開始：當檔案進入保險庫後，明文到底停在哪裡，雲端又能看到什麼？只有把這條邊界說清楚，後面的金鑰派生、檔案加密、分享轉存和流式播放才有穩固的基礎。

1. 端對端加密邊界

保險庫做的第一件事，是把「看得懂檔案」這件事留在你的裝置上。檔案內容、檔案屬性和金鑰材料會先在本地完成加密，再交給雲端做儲存、同步與傳輸。從產品流程看，它仍然像你熟悉的雲端硬碟：從應用入口進入使用者空間，再進入保險庫或分享空間；但真正能把密文還原成明文的能力，只留在授權客戶端。

服務端仍然負責檔案儲存、同步狀態、分享索引與傳輸調度。它可見和保存的主要資料包括：

• 加密後的檔案內容，也就是密文塊。
• 加密後的元資料，例如檔案屬性、加密檔案金鑰、分塊描述資訊等。
• 與帳號或分享相關的加密主金鑰材料、分享標識和必要索引。

服務端不需要直接持有：

• 明文檔案內容。
• 明文主金鑰。
• 各檔案的明文檔案金鑰。
• 可直接解密檔案的完整金鑰鏈路。

這條邊界是整套保險庫設計的起點：雲端繼續負責把檔案可靠地存好、同步好，明文恢復能力則牢牢限制在授權客戶端內。

2. 安全目標與設計對應

安全設計最怕只剩一串演算法名稱。對保險庫來說，我們更在意每個安全目標在系統裡落在哪裡：哪一步保護機密性，哪一步阻止篡改，哪一步把金鑰影響面收住。下面這張表，就是把這些目標和具體工程位置對上。

安全目標	實現要點
機密性	檔案內容使用 AES-256-GCM；每個檔案使用獨立檔案金鑰；主金鑰材料加密後上雲。
完整性	GCM 認證標籤用於校驗密文塊；校驗失敗時拒絕輸出明文。
金鑰隔離	透過多級派生拆分主金鑰、元資料金鑰、檔案金鑰與分享密鑰。
最小暴露	分享使用獨立分享密鑰；轉存時使用接收方帳號金鑰重新封裝。
身份與防篡改	支援 Ed25519 數位簽名與驗簽，可用於對相關業務訊息做身分校驗。
本地訪問控制	本地解密播放鏈路使用隨機訪問令牌，降低同機進程任意拉取明文流的風險。
可演進性	金鑰派生與加密套件帶版本資訊，便於後續演算法升級與歷史資料兼容。

3. 多級金鑰派生

如果用一把主金鑰包打天下，實作可能最直覺，但風險也會被放大。保險庫選擇樹狀金鑰派生模型，把帳號級、檔案元資料級、檔案級與分享級場景拆開，讓每把金鑰只做自己該做的事。

可以把它想成一棵帶用途標籤和版本標籤的金鑰樹：

使用者憑證（保險庫密碼 / 12 詞助記詞）+ 客戶端隨機因子
  -> PBKDF2 或助記詞恢復
  -> 主金鑰
  -> HKDF，帶用途標籤與版本標籤
  -> 檔案域根材料
  -> 按檔案標識派生檔案元資料金鑰
  -> 加密檔案屬性、檔案金鑰、分塊描述資訊

分享密鑰則另起一條分支，由分享上下文單獨派生，只服務分享鏈路，不和日常檔案加密路徑混用。

這種拆法帶來幾個很實際的工程價值：

• 用途分離：不同金鑰派生標籤對應不同用途，避免同一金鑰材料被重複用於多個安全上下文。
• 影響面收斂：單個檔案金鑰洩露，不應自然推導出其他檔案的檔案金鑰。
• 版本演進：派生標籤中包含版本資訊，可支援後續密碼套件升級。
• 帳號恢復：雲端保存的是加密後的主金鑰材料，而不是明文主金鑰。
• 統一入口：使用者完成開啟或解鎖保險庫後，後續上傳、下載、分享、轉存共用同一套派生規則，業務層不需要重複實作密碼學細節。

密碼學底座我們沒有從零發明，而是基於 OpenSSL 等成熟元件構建，包括 PBKDF2、HKDF、AES-256-GCM 與 Ed25519；在對隨機源品質更敏感的環境中，也可按需向隨機數生成器注入額外熵。

4. 檔案加密與元資料保護

檔案加密是保險庫的核心鏈路。當客戶端拿到一個檔案時，它會先為這個檔案生成唯一標識，再生成該檔案專屬的檔案金鑰，然後用檔案元資料金鑰把這把檔案金鑰包裝起來，形成可以安全上傳到雲端的加密檔案金鑰。接下來，客戶端會寫入分塊描述資訊，記錄明文長度、加密套件版本、分塊大小和密文偏移等布局資訊，最後按塊讀取本地檔案並以 AES-GCM 逐段輸出密文與認證標籤。

這一串動作聽起來很底層，但目的很清楚：每個檔案有自己的檔案金鑰，每個分塊有自己的認證結果，雲端拿到的是可以同步和傳輸的密文，而不是可以直接閱讀的檔案。分塊大小會根據檔案大小在約 64 KB 到 4 MB 區間內自適應選擇。小檔案可以減少元資料與調度開銷，大檔案可以降低加解密呼叫頻率並提高吞吐。分塊描述資訊則使用 Protocol Buffers 之類的結構化二進位格式序列化，這樣在不同版本與不同平台之間，解析出的布局語義才會保持一致。

保險庫的保護對象不只包括檔案正文，也包括部分元資料。檔名、目錄結構、業務屬性、檔案金鑰的包裝結果，以及分塊描述資訊本身，都會被納入保護範圍。原因很直接：即使檔案內容已經被加密，元資料仍然可能洩露內容類型與使用習慣，所以保險庫把元資料加密視作端對端模型的一部分，而不是可有可無的附加層。

還有一個需要刻意處理的細節是 Nonce 的唯一性。保險庫並不是隨機重用一個外部 Nonce，而是把檔案標識與塊序號共同納入派生過程，讓同一檔案內不同分塊、以及不同檔案之間的加密上下文都能保持清楚的區分，從而滿足 GCM 對 Nonce 唯一性的要求。

5. 加密分享與轉存

加密分享要解決的核心問題不是「能不能分享」，而是如何讓接收方讀到被授權的檔案，同時又不把分享者的帳號主金鑰暴露出去。PikPak 的做法是把分享當成一個獨立的加密上下文：分享者先生成分享標識，客戶端再根據這個分享上下文派生分享密鑰，並透過安全渠道把分享密鑰單獨交給接收方。隨後，被分享檔案所需的元資料金鑰材料會被分享密鑰重新包裝，服務端保存的仍然只是分享索引、被包裝後的金鑰材料與密文檔案。

對接收方而言，進入分享空間後能做的事情是本地解密被授權內容，而不是向服務端索取一把可還原整個帳號的通用金鑰。當接收方決定把檔案轉存到自己的保險庫時，系統會再次進行金鑰重封裝：先在分享上下文中解開必要的檔案金鑰材料，再使用接收方帳號下的檔案元資料金鑰重新加密檔案金鑰與檔案屬性，最後把新的加密檔案金鑰與加密檔案屬性寫入接收方自己的雲端空間。這樣一來，轉存後的檔案就完全納入接收方自己的金鑰體系，不再依賴分享者的帳號路徑。

6. 流式加解密與 Range 訪問

對大檔案、影片和音訊而言，等整個檔案下載完成再解密並不現實，所以保險庫把明文區間和密文區間建立了直接映射。上層如果只需要某一段明文，客戶端就會先根據分塊描述資訊算出對應的密文範圍，然後只拉取必要的密文片段，在本地按塊完成校驗與解密。

這樣做帶來的結果很直接：下載與上傳都可以與遠端已確認進度對齊，播放器拖動進度條時只需要新的 Range 請求，記憶體也不必一次性承載整個檔案。本地播放場景下，客戶端會在 127.0.0.1 啟動一個輕量 HTTP 解密代理，系統播放器仍然沿用標準 HTTP Range 請求，但真正的密文定位、GCM 校驗和解密都留在本地客戶端內。播放地址會帶上本地訪問令牌，這樣可以把明文流的可見範圍限制在當次播放會話內。

下載鏈路也遵循同樣的思路：客戶端只請求目標區間需要的密文，邊接收、邊校驗、邊解密，任務結束或取消時再釋放臨時持有的資料。播放鏈路則會透過會話佇列與發送緩衝上限協調解密與輸出速率，避免解密速度快於消費速度時把記憶體撐高。

7. 上傳側的分塊加密與進度同步

上傳側並沒有引入另一套與下載完全不同的模型，而是沿用了同樣的分塊思想，只是方向反過來。系統會先查詢遠端已接收、已確認的位元組數，然後從對應偏移繼續產生密文，再把密文塊逐段上傳到服務端。服務端關心的是傳輸調度和進度確認，因此可以用狀態機把「查詢進度、繼續上傳、確認完成」這條鏈路串起來，但它不需要理解其中的明文內容。

這種做法的好處是，上傳不是一個一次性的大請求，而是一條可以暫停、恢復、取消和查詢進度的持續鏈路。對使用者來說，它和流式下載形成對稱的體驗；對系統來說，則避免了把整個檔案一次性推入上傳緩衝。

8. 跨平台實現

保險庫底層以 C++ 核心庫和 C 語言介面交付，這讓同一套密碼學與資料格式邏輯可以在不同平台之間復用，而不必為每個客戶端重寫一套加解密實現。目標平台覆蓋 iOS、Android、macOS、Windows、Linux 以及現代瀏覽器環境。跨平台核心的價值不只是在裝置數量上擴展，更重要的是讓同一份加密資料在不同端上遵循完全一致的金鑰派生、分塊描述、Nonce 派生、認證校驗與解密流程。

9. 典型生命週期

從使用者操作看，保險庫的生命週期其實很清楚。當使用者開啟或解鎖保險庫時，客戶端先接收使用者憑證或 12 詞助記詞，再透過 PBKDF2 或助記詞恢復主金鑰材料，然後解開雲端保存的加密主金鑰材料，最後初始化檔案域、分享域和簽名域等派生上下文。從那一刻開始，後續所有操作都會基於同一套派生規則展開。

上傳檔案時，客戶端先生成檔案標識與檔案金鑰，再依據檔案大小選擇分塊策略，然後生成並加密分塊描述資訊。檔案正文會被按塊加密，每個塊都會產生自己的密文和 GCM 認證標籤，最後連同加密檔案金鑰、加密檔案屬性與加密分塊描述資訊一起上傳，服務端只需要確認已接收與已提交進度即可。

下載或播放的順序剛好相反。客戶端先解密檔案屬性、檔案金鑰與分塊描述資訊；如果是完整下載，就按分塊順序拉取密文並解密，如果是 Range 播放，就先把明文區間映射到密文區間，再只拉取必要的密文並逐塊校驗 GCM 標籤。校驗通過後才輸出明文，校驗失敗則直接拒絕輸出。

分享與轉存同樣遵循這個模型。分享者建立加密分享後，客戶端會派生分享密鑰並用它包裝被分享檔案所需的金鑰材料，接收方進入分享空間後可以在本地解密被授權內容；如果接收方把檔案轉存到自己的保險庫，客戶端還會用接收方自己的元資料金鑰重新包裝檔案金鑰與檔案屬性，讓轉存後的檔案真正進入接收方自己的金鑰體系。

10. 實作注意事項

這類設計的風險往往不在某一個演算法本身，而在邊界是否被破壞。實作時要盯住幾件事：Nonce 不能重複，因為分塊序號、檔案標識和加密套件版本必須共同保證上下文唯一性；GCM 校驗失敗必須直接拒絕輸出明文，不能退化成警告或容錯讀取；元資料加密不能只覆蓋檔名，分塊描述資訊和檔案金鑰包裝結果也要納入保護；分享鏈路不能暴露帳號主金鑰，轉存也不能直接沿用分享者的包裝結果；本地 HTTP 解密代理應該使用短期、隨機、並且和檔案與空間綁定的訪問令牌；所有派生標籤、加密套件與資料格式都應帶版本資訊，避免未來升級與歷史資料衝突；跨端實作還需要共用同一套測試向量，覆蓋金鑰派生、分塊描述解析、Nonce 派生、GCM 驗證和 Range 映射。

小結

PikPak 保險庫並不是在一般雲端檔案上簡單增加一道保險庫密碼，而是圍繞端對端加密重新設計了檔案儲存、金鑰管理、分享轉存和流式訪問鏈路。

它的核心不是把某個加密演算法包裝成賣點，而是把客戶端加密、金鑰隔離、元資料保護、分享與轉存、Range 播放和跨平台一致性串成一條完整的工程鏈路。檔案在客戶端加密，雲端只處理密文；主金鑰、元資料金鑰、檔案金鑰與分享密鑰分層隔離；檔案正文與關鍵元資料一起進入保護模型；分享和轉存透過金鑰重封裝降低帳號金鑰暴露；Range 映射與本地解密代理讓大檔案播放和斷點續傳保持可用；跨平台核心則保證多端語義一致。對雲端儲存產品而言，安全與體驗必須同時成立，而這套設計正是把這兩件事放在同一條工程路徑上來處理。