App 中的合理否認性：是什麼及為何重要
合理否認性意味著隱藏資料的存在無法被證明。
加密中的合理否認性是一種儲存特性：使用者可以公開一組資料，而不留下任何能證明另一組資料存在的結構痕跡。這種主張必須講明威脅模型：一份正確填充的加密儲存區的靜態映像檔，和一部正在運作且已遭入侵的裝置、雲端服務中繼資料，或存放在別處的副本，是不同的情況。它不只是一個隱藏功能，而是要靠加密、儲存配置、填充和操作設計共同配合。
本指南說明合理否認性在 App 中的運作方式、真正密碼學否認性與表面上的誘餌模式的區別、它重要的真實世界情境，以及如何評估否認性主張。
加密中的合理否認性是什麼意思
在日常用語中，合理的否認意味著你可以可信地否認某件事。在儲存密碼學中，實用的目標更窄：在所述的威脅模型內，檢查加密儲存區的人不應能分辨隱藏內容和未使用的填充空間。沒有任何 App 能把這項承諾延伸到已開啟的保險庫、被記錄下的輸入、外部副本，或各種形式的裝置入侵。
這個概念起源於磁碟加密。TrueCrypt（及其後繼者 VeraCrypt）首創了隱藏磁碟區：在一個加密磁碟區裡再放一個加密磁碟區。一組密碼開啟放著無害檔案的外層磁碟區，另一組密碼開啟放著敏感檔案的內層隱藏磁碟區。鑑識人員無法確定隱藏磁碟區是否存在，因為外層磁碟區中未使用的空間填滿了隨機資料，與加密資料無從分辨。
對於 App，合理否認性意味著不同的憑證（密碼、PIN、圖形）開啟不同的資料集，而且沒有任何中繼資料、登錄表、設定標記或結構痕跡會洩漏額外資料集的存在。
真正的否認性 vs. 表面上的誘餌模式
這是大多數 App 犯錯的關鍵區別。
表面上的誘餌模式（非真正的否認性）
許多保險庫 App 提供「誘餌」或「假 PIN」功能，你可以設定第二組 PIN，開啟另一個放著不同照片的空間。問題在於：這些 App 通常會儲存一個布林標記、一筆資料庫項目或一個設定檔，顯示誘餌模式存在且已設定。
熟悉該 App 的鑑識人員可以找到這個標記。只要找到已設定的誘餌模式，就能證明隱藏資料存在。這種否認性只是表面功夫，擋得住隨手偷看的人，卻經不起鑑識檢查。
表面否認性的跡象：
- App 在設定中有「誘餌模式」切換
- 設定檔儲存誘餌模式是否已啟用
- 資料庫表格列出保險庫 ID，並標示類型（主要/誘餌）
- 開啟誘餌模式後 App 的儲存結構發生變化
- 解除安裝並重新安裝 App 後，有設定誘餌模式時的行為會不一樣
真正的密碼學否認性
真正的否認性是一種架構屬性，而非功能切換。加密儲存的設計必須做到：
每組備用憑證只公開自己的資料集。系統不會另外保存把某組憑證標為誘餌的標記。無效的憑證可以失敗，但失敗本身不得透露是否存在未公開的資料集。
不存在保險庫登錄表。App 無法列舉存在多少個保險庫，沒有計數、沒有索引、沒有保險庫 ID 清單。鑑識人員檢查 App 儲存空間時，只會看到一整池無從區分的加密資料。
沒有任何設定標記會洩漏隱藏保險庫。沒有布林值、沒有資料庫條目、沒有偏好設定檔顯示是否有額外的保險庫存在。
儲存空間經過填充。無論有多少保險庫或檔案，佔用的總儲存空間都不變。若沒有填充，檢查者可以比較加密資料的總大小與可見內容，估算出保險庫數量。
加密資料與隨機雜訊無法區分。沒有檔案邊界、沒有標頭，也沒有任何結構標記能看出一個保險庫的資料在哪裡結束、另一個從哪裡開始。
| 屬性 | 表面誘餌 | 真正否認性 |
|---|---|---|
| 每個憑證有獨立資料 | 是 | 是 |
| 無保險庫登錄表 | 否（資料庫追蹤保險庫） | 是 |
| 無設定標誌 | 否（誘餌切換已儲存） | 是 |
| 儲存填充 | 很少 | 是 |
| 在靜態映像檔中隱藏備用儲存區 | 否 | 是，在所述的儲存威脅模型內 |
| 架構 vs. 功能 | 功能切換 | 架構屬性 |
這很重要的真實世界情境
合理否認性不是理論上的擔憂，它針對的是有據可查、反覆出現的真實世界情況。
邊境過境
在過境時，檢查人員可能會檢查裝置並要求提供憑證。如果設計真的提供儲存層級的否認性，一組憑證可以只公開無害的資料集，而靜態映像檔中也沒有能區分隱藏內容與填充的結構標記。Vaultaire 目前的儲存配置讓能存取 App 容器的檢查者可以估計保險庫數量，因此無法提供這項保證。
家暴與控制型關係
處於虐待關係中的人可能需要在施暴者監控的裝置上儲存證據（傷害照片、威脅訊息、法律文件）。若施暴者要求查看保險庫，使用者可以開啟包含非敏感內容的保險庫。沒有真正的否認性，App 設定中的「誘餌模式」標誌就會揭示隱藏內容的存在。
裝置被竊
懂技術的小偷可能會試圖從被偷的手機中取出資料。經過適當填充的可否認儲存，目的是隱藏儲存池裡有幾組資料集，不過總配置量、裝置狀態、備份和操作痕跡仍屬於威脅模型的一部分。Vaultaire 目前會加密內容，但儲存 arena 的數量仍限定了有多少個保險庫存有檔案。
法律和新聞保護
保護消息來源的記者、保護客戶檔案的律師以及威權政體中的活動人士，都可能遇到被迫交出裝置內容的情況。真正的否認性讓他們在資料遭扣押時，仍有可信的抗辯。
Vaultaire 今天實施了什麼
Vaultaire 提供以不同圖形分隔的存取方式，正常介面也不顯示保險庫清單。這些設計能減少日常使用時介面洩漏的資訊，但並不構成真正的密碼學合理否認性；能存取 App 容器的人仍可估計保險庫數量：
已設定的圖形各自開啟獨立的加密保險庫。PBKDF2 從圖形和全裝置共用的鹽值衍生出保險庫金鑰。已設定的金鑰會驗證自己的加密索引，並解開一把隨機主金鑰。未設定的圖形會顯示空白狀態，而不是「圖形錯誤」的訊息。
本機格式仍可讓人估計保險庫數量。Vaultaire 為每個保險庫存放一個 vault_index_<locator>.bin 根檔案，和掩護檔案一起放在 64 個以上的檔案池中。所有保險庫的頁面和儲存 arena 都以隨機名稱放在同一個資料夾裡。這些名稱不會洩漏圖形、保險庫名稱或檔案屬於哪個保險庫，但 arena 數量限定了有多少個保險庫存有檔案，所以能存取 App 容器的人仍可估計這個數字。AES-GCM 驗證和固定的檔案名稱，也讓人能離線測試候選的保險庫金鑰。
本機儲存的大小並不固定。檔案內容和中繼資料都經過加密，雲端備份區塊也使用大小填充和誘餌記錄。根檔案和掩護檔案放在同一個池中，掩護 arena 也讓 arena 數量維持在固定級距，但 arena 數量、目錄頁數、檔案時間和總儲存量仍會洩漏結構。
復原與脅迫狀態確實存在。Vaultaire 把復原資訊存放在以 AES-GCM 加密的 Keychain 資料庫中。脅迫模式會刪除這台裝置上其他保險庫的索引、頁面和儲存 arena（一般的檔案刪除，不會覆寫），清除復原資料，並讓該裝置脫離同步。它不會清除雲端備份或其他裝置上的副本，完成所需時間則取決於本機要處理的工作量。
因此，Vaultaire 提供的是介面上的區隔和加密儲存，而不是在資訊理論上證明沒有其他保險庫。1.0.17 版推出的儲存格式隱藏了哪些檔案屬於哪個保險庫，但它的 arena 數量仍讓離線的 App 容器快照能推出保險庫數量的上限。
如何評估否認性主張
當 App 聲稱具有合理否認性時，詢問：
- 有「誘餌模式」切換嗎？若有，那是表面上的，鑑識檢查員可以找到切換。
- App 有保險庫清單或資料庫嗎？若有，保險庫的存在是可證明的。
- 猜測可以離線驗證嗎？經過驗證的密文不需要另外的密碼雜湊，就能驗證候選金鑰。請問清楚是什麼在限制猜測的成本，以及儲存配置是否提供了更容易利用的金鑰指紋。
- 儲存消耗量會隨保險庫數量變化嗎？若有，磁碟分析可以估計保險庫數量。
- App 可以列舉保險庫嗎？若 App 可以顯示你的保險庫清單，該清單就存在於裝置上並可被發現。
常見問題
合理否認性合法嗎？
在大多數民主國家，使用具有合理否認性的加密是合法的。沒有法律禁止在裝置上存在無法證明其存在的加密資料。在某些司法管轄區（英國依 RIPA、澳大利亞依《協助與存取法》），當局可以強制披露加密金鑰。法律問題在於強制披露無法證明其存在的資料的金鑰是否可執行，這仍是一個發展中的法律領域。
鑑識工具能偵測合理否認性嗎？
取得 Vaultaire App 容器的檢查者可以偵測到加密儲存。vault_index_*.bin 根檔案與掩護檔案一起放在 64 個以上的檔案池中，所有保險庫的頁面和儲存 arena 都以隨機名稱放在同一個資料夾裡。檔名看不出檔案屬於哪個保險庫，但 arena 數量限定了有多少個保險庫存有檔案，所以檢查者仍可估計你有幾個保險庫。這些檔案不會洩漏保險庫名稱或明文內容。因此，目前的設計是讓保險庫在一般操作中看不到，而不是在每一種鑑識儲存檢查中都看不到。
合理否認性能對抗鐵了心的國家級對手嗎？
只要金鑰、nonce 和實作都正確，AES-256-GCM 就能為內容加密提供強固的邊界。但這不代表 Vaultaire 目前的儲存配置能在國家級檢查者面前維持否認性：檢查者仍可估計本機保險庫數量，而且在保險庫開啟時，即時入侵可以鎖定圖形、金鑰、預覽或匯出內容。目前的功能是在介面上區分不同圖形能開啟的內容，並不保證鐵了心的檢查者無法證明還有其他本機索引存在。
合理否認性和隱藏保險庫有什麼區別？
隱藏保險庫不會出現在 App 的鎖定介面。密碼學上的合理否認性要求更嚴格：可觀察的儲存結構不能證明另有受保護內容。Vaultaire 不顯示跨保險庫清單，每個有效圖形只導向所屬保險庫；但能存取 App 容器的檢查者目前仍可估計保險庫數量，因此提供的是介面分隔，而不是讓檔案系統檢查無法證明其他本機索引存在。
我可以在雲端備份中使用合理否認性嗎？
Vaultaire 會把加密的備份清單和經過填充的加密檔案區塊，寫入使用者私人的 CloudKit 資料庫。資料記錄的隨機名稱、10 MB 區塊填充和誘餌記錄，可以減少內容被直接洩漏。記錄數量、總量、時間和更新模式仍是看得到的服務中繼資料，所以雲端備份無法形成大小固定、在資訊理論上可否認的儲存區。
總結
強大的儲存否認性，目的是讓檢查者無法在靜態加密儲存區中分辨隱藏資料和經過填充的空白空間。大多數宣稱有這項功能的 App，提供的只是表面上的誘餌模式，設定標記一找就到。要達到更嚴格的定義，需要明確的威脅模型、無法計數的保險庫登錄、不會洩漏資訊的設定標記、穩定的填充，以及不會暴露哪些槽位是真實的加密記錄。
Vaultaire 用已設定的圖形區隔各個加密保險庫，並讓保險庫名稱和內容不出現在鎖定畫面上。它目前的儲存配置，仍會讓檢查 App 容器的人估計出保險庫數量。請把它看成以驗證加密為後盾的介面層級隱藏，而不是沒有其他保險庫的證明。