安全架構：完整技術堆疊

Vaultaire 使用 AES-256-GCM，對保險庫索引、包裹後的金鑰、檔案標頭、內容、縮圖和中繼資料進行驗證式加密。PBKDF2-HMAC-SHA512 以圖形和全裝置共用的 Keychain salt 衍生出本機保險庫金鑰。這把保險庫金鑰會包裹另一把獨立的隨機 256 位元主金鑰，再由主金鑰在 App 程序中透過 CryptoKit 加密檔案。

密碼學堆疊

Vaultaire 使用多種相互配合的密碼學機制，每一種都為特定工作而選。PBKDF2 把人記得的憑證轉成保險庫金鑰或復原金鑰。AES-256-GCM 保護索引、金鑰包裝、中繼資料、縮圖和檔案內容。隨機主金鑰讓長期使用的檔案加密和可以更改的圖形彼此分開。裝置鎖定時，Keychain 和 iOS 資料保護會保護綁定裝置的 salt 和復原記錄。開發者沒有任何由服務方持有的解密金鑰，無法在日常情況下存取保險庫明文。

這不是為了複雜而複雜。每一層各自應對不同的攻擊面。AES-256-GCM 同時提供機密性與驗證，遭修改的密文無法通過驗證。PBKDF2 提高了測試每個圖形或片語的成本。有了隨機主金鑰，更改圖形時只需重新包裹一把金鑰，不必重新加密每個檔案。Keychain 資料保護守護本機的 salt 和復原記錄，而 App 也坦白說明，對稱加密是在程序記憶體中進行。

這些層共同構成縱深防禦架構，但它們並非全都是彼此獨立的屏障。猜測的圖形可以拿索引檔案名稱和 AES-GCM 驗證來核對，而已遭入侵且處於解鎖狀態的裝置，也能觀察到 App 程序中的金鑰或明文。因此，這套架構除了取決於 AES 本身的強度，也取決於憑證的熵、PBKDF2 成本、iOS 裝置保護，以及驗證式加密是否處理正確。

AES-256-GCM：檔案加密

Vaultaire 中儲存的每張照片、影片和文件都以 AES-256-GCM 加密，也就是採用 256 位元金鑰、以Galois/Counter 模式運作的進階加密標準。Vaultaire 也用 AES-GCM 加密保險庫索引、檔案標頭、縮圖和金鑰信封。演算法和金鑰長度都是標準化的，但 Vaultaire 的安全性仍取決於隨機數處理、金鑰管理、憑證強度和實作是否正確。

AES-256 中的「256」指的是金鑰長度（位元）。256 位元金鑰有 2²⁵⁶ 種可能的值。換個角度看這個數字：可觀測宇宙中大約有 10⁸⁰ 個原子。若每個原子都是一台超級電腦，每秒測試十億個金鑰，從宇宙大爆炸開始運行至今，它們探索過的金鑰空間也還不到兆分之一的兆分之一個百分點。AES-256 不會被暴力破解。今天不會，這個世紀不會，直到恆星燃盡也不會。

為什麼 GCM 模式很重要

AES 是一種區塊密碼，以 128 位元為一個區塊加密資料。「模式」決定這些區塊如何組合。GCM（Galois/Counter 模式）提供了 CBC 等較簡單模式所沒有的兩樣東西：平行加密和內建驗證。

驗證這部分非常關鍵。GCM 會為每個加密檔案產生一個密碼學標籤，作用就像防拆封條。只要密文有任何一個位元被修改，不論是惡意攻擊者所為還是磁碟磁區損壞，驗證標籤就會對不上，解密也會失敗。你不會拿到損壞的資料，而是收到出問題的明確訊號。這種特性稱為驗證式加密，能防止攻擊者藉由修改加密資料來操控解密結果的一整類攻擊。

PBKDF2：金鑰衍生

Vaultaire 會為不同用途衍生不同的金鑰。圖形和全裝置共用的 Keychain salt 經過 PBKDF2-HMAC-SHA512 迭代 600,000 次，產生本機保險庫金鑰。另一個確定性的圖形衍生流程會產生獨立的雲端備份金鑰。正規化後的復原片語經過 800,000 次 PBKDF2 迭代，產生復原信封的金鑰。這些衍生過程都不會只因輸出長度是 256 位元，就讓人記得的憑證擁有 256 位元的熵。

PBKDF2 如何保護你的圖形

PBKDF2 的核心概念是刻意增加運算量。它把序列化後的圖形或正規化後的片語拿去執行數十萬次 HMAC-SHA512 迭代。合法使用者在解鎖或復原時只需付出一次這個成本，攻擊者則要為每個候選值都付出一次，不過實際的猜測速度仍取決於平行運算硬體和實作方式。

Vaultaire 為圖形衍生的金鑰設定 600,000 次 PBKDF2 迭代。這讓每次猜測的成本更高，但負責任的攻擊估算必須說明每個候選值的實測耗時和硬體假設。若每個候選值剛好耗時 1 毫秒，連續猜 10 億次大約需要 11.6 天，而不是好幾年。256 位元的輸出並不會增加可預測圖形的熵。

本機的圖形衍生使用一個以密碼學方式隨機產生的裝置 salt，儲存為 WhenUnlockedThisDeviceOnly 的 Keychain 項目。這個 salt 不是秘密，由該裝置上的所有保險庫共用。它能防止為某台裝置建立的對照表直接套用到 salt 不同的另一台裝置，但不會迫使攻擊者針對同一裝置上的每個保險庫重新來過。

AES-256-GCM：中繼資料保護

僅加密檔案內容是不夠的。檔案名稱、建立日期、縮圖尺寸和保險庫結構都是中繼資料，而中繼資料可能和資料本身一樣具有揭示性。名為「tax-return-2025.pdf」的檔案，即使內容是加密的，也向攻擊者準確揭示了裡面是什麼。時間戳記會顯示你何時使用保險庫。縮圖大小揭示了某東西是照片還是影片。

Vaultaire 用 AES-256-GCM 保護這些中繼資料，而不是 ChaCha20。檔案名稱和 MIME 類型會編入加密的檔案標頭。加密的保險庫索引包含檔案記錄、日期、大小資訊、儲存配置和包裹後的主金鑰。縮圖資料也以隨機主金鑰加密。

為什麼中繼資料要用驗證式加密？

中繼資料需要完整性，也需要機密性。AES-GCM 會為每個加密值產生驗證標籤，因此 Vaultaire 能拒絕遭修改的標頭、索引、縮圖或信封，而不會接受攻擊者控制的明文。這項設計刻意在這些儲存格式中統一使用一種驗證式加密結構，而不宣稱實作中並不存在的密碼演算法多樣性。

使用同一種密碼演算法，不代表會盲目重複使用同一把金鑰或同一個隨機數。保險庫金鑰保護索引並包裹隨機主金鑰，主金鑰則保護檔案資料。CryptoKit 以全新的隨機數建立經過驗證的密封盒，而 Vaultaire 的串流格式會為每個依序排列的區塊衍生不同的隨機數。相關保證來自金鑰分離、嚴謹的隨機數管理和驗證機制，而不是來自另一套中繼資料專用的密碼演算法。

零知識架構

對任何安全 App 都值得問一個問題：如果背後的公司遭駭、收到傳票，或乾脆心懷不軌，會發生什麼事？

對大多數 App 來說，答案令人不安。它們持有你的資料、你的金鑰，或兩者皆有。法院命令可以迫使它們交出資料，資料外洩會讓資料曝光，心懷不軌的員工也能存取。App 的安全性只和公司的營運安全一樣強，而歷史顯示，公司遭駭是常有的事。

Vaultaire 沒有經營任何會收到你的圖形、秘密片語、解密金鑰或可讀保險庫內容的帳號或儲存服務。加密和解密都在你裝置上的 App 程序中進行。啟用 iCloud 備份時，App 會把經過驗證的密文傳到你私人的 CloudKit 資料庫，而不是由 Vaultaire 控制的保險庫服務。

零知識在實踐中的意義

如果執法機關對 Vaultaire 發出傳票，要求提供保險庫明文，公司手上並沒有解密所需的圖形、復原片語、保險庫金鑰、備份金鑰或主金鑰。加密的 iCloud 記錄存放在使用者的 CloudKit 私人資料庫中。不過在裝置上，復原資料保存在加密的 Keychain 資料庫裡，而 CryptoKit 加密或解密已開啟的保險庫時，對稱金鑰會存在於 App 記憶體中。

這條服務方邊界是架構上的特性，並不是保證用戶端環境的每個部分都在信任模型之外。Vaultaire 沒有可以交出、用來例行復原保險庫的伺服器端解密金鑰。但發行的 App、iOS、已解鎖的裝置和密碼學實作仍會處理可讀資料，因此仍須信任它們。

Keychain 與 App 程序邊界

Apple 的 Secure Enclave 能保護它支援的私密金鑰，也參與部分平台安全架構，但它的公開 API 無法接收任意由 PBKDF2 衍生的對稱金鑰，並在這顆協同處理器內執行 Vaultaire 的 AES-GCM 檔案運算。因此，Vaultaire 不會把它的保險庫加密說成 Secure Enclave AES。

Vaultaire 以一般的 iOS Keychain 通用密碼項目，存放隨機裝置 salt、加密的復原資料庫，以及保護該資料庫的隨機金鑰。這些項目使用 WhenUnlockedThisDeviceOnly 存取類別。Keychain 和資料保護建立了實質的裝置邊界，在手機鎖定時尤其如此，但這種架構和無法匯出的 Secure Enclave 金鑰不同。

你畫出圖形時，CommonCrypto 會在 App 程序中衍生保險庫金鑰。接著 CryptoKit 和 Vaultaire 的 CryptoEngine 在同一個程序中使用對稱金鑰位元組，驗證並解密索引、解開主金鑰和處理檔案。App 鎖定時會清除作用中的狀態，但能觀察已解鎖工作階段、權限足夠的攻擊者，和只拿到鎖定裝置密文的鑑識人員，所擁有的機會並不相同。

已越獄或以其他方式遭入侵的作業系統，可以鎖定圖形輸入、App 記憶體、解密後的預覽、匯出內容或螢幕畫面。Vaultaire 建議使用最新且未越獄的 iPhone，因為這套設計仰賴 iOS 的程序隔離、Keychain 和資料保護。它並未宣稱在 root 權限遭入侵時，已開啟保險庫的對稱金鑰仍無法被存取。

每個檔案的初始化向量

用同一把金鑰加密兩個相同的檔案時，天真的實作會產生相同的密文。這是個問題。攻擊者只要看到兩個相同的加密 blob，不必解密就知道兩個原始檔案是一樣的。在存滿照片的保險庫中，這種規律分析即使隔著加密也能洩漏資訊。

Vaultaire 為每一次 AES-256-GCM 密封操作產生全新的密碼學隨機數，避免產生確定性的密文。檔案標頭和檔案內容分開密封，大型檔案則使用經過驗證的串流格式，包含一個隨機的基礎隨機數，並為每個依序排列的區塊使用不同的隨機數。因此，同一張照片的兩個副本不會產生相同的加密結果。

隨機數和密文存放在一起，不是秘密；它們的安全要求是在同一把金鑰下不重複。Vaultaire 進行單次加密時，會向 Apple 的密碼學隨機產生器取得 96 位元的隨機數，並把基礎隨機數記錄在串流標頭中。碰撞風險取決於同一把金鑰加密的次數，因此實作會每次產生新值，而不是把 96 位元的長度說成固定的 2⁹⁶ 分之一終身保證。

記憶體管理：清除作用中的金鑰狀態

安全軟體常見的失誤，是在敏感資料用完後仍把它留在記憶體中。加密金鑰、衍生出的密碼和解密後的資料，可能在 App 用完之後很久都還留在 RAM 裡。鑑識工具可以傾印裝置記憶體並搜尋這些殘留資料，這種技術稱為冷開機攻擊或記憶體傾印分析。

Vaultaire 會限制作用中的金鑰狀態和解密後的 UI 資料保持可用的時間。App 鎖定或工作階段結束時，程式碼會執行幾道清理流程：

• 捨棄作用中的保險庫狀態。 App 會移除目前的保險庫金鑰工作階段，必須再次解鎖才會顯示保險庫內容。
• 金鑰包裝容器清除自有的緩衝區。 Vaultaire 的安全位元組容器在釋放時，會覆寫它們自己持有的緩衝區。
• 讓快取的主金鑰狀態失效。 為已開啟索引保存的解密主金鑰，會在相關的鎖定和快取重設流程中被捨棄。
• 清除 Vaultaire 能控制的解密 UI 快取。 清理縮圖和預覽可減少殘留的 App 狀態，但不宣稱能控制 Swift、iOS 或其他程序產生的每一份副本。

下次 Vaultaire 在鎖定狀態下開啟時，你要畫出圖形，App 會重新衍生保險庫金鑰，然後才能驗證索引並解開主金鑰。這是工作階段清理，並不是宣稱每個暫時的記憶體副本都經過可證明的多次覆寫，也不是宣稱某個 Secure Enclave 金鑰參照已被銷毀。當機時 iOS 會回收程序，但清理程式碼無法在每次突然終止後都執行。