跳至內容

靜態數據加密

出自 Arch Linux 中文维基

相關文章

本文討論靜態數據加密軟體，該軟體即時加密/解密寫入/讀取塊設備、磁碟分區或目錄的數據。塊設備的示例是硬碟驅動器、快閃記憶體驅動器和 DVD。

靜態數據加密僅應被視為作業系統現有安全機制的附屬品——專注於保護物理訪問，同時依賴系統的其他部分提供網絡安全和基於用戶的訪問控制等功能。

對於全盤加密 (Full-disk encryption，FDE)，參閱Dm-crypt/加密整個系統。

為什麼要使用加密？

靜態數據加密確保文件始終以加密的形式存儲在磁碟上。這些文件只有在系統運行並由受信任的用戶解鎖時才以可讀形式提供給作業系統和應用程式（使用中的數據或傳輸中的數據）。未經授權的人直接查看磁碟內容，只會發現混亂的隨機數據，而不是實際的文件。

例如，這可以防止未經授權的數據查看，當電腦或硬碟：

  • 處於當你離開時不受信任的人可能獲得使用機會的場所
  • 丟失或被盜，如筆記本電腦、上網本或外部存儲設備
  • 在維修店裡
  • 淘汰後被丟棄

此外，靜態數據加密還可用於增加一些安全性，以防止未經授權的篡改作業系統的嘗試——例如，可以獲得物理訪問權限的攻擊者趁你不在的時候安裝鍵盤記錄程序（keyloggers）或特洛伊木馬（Trojan）。

警告：靜態數據加密並不能保護你的數據免受所有威脅。

你仍面臨以下潛在風險：

  • 攻擊者可能在系統運行期間，且你已經解鎖並掛載了磁碟的加密部分時入侵系統（如通過網際網路）。
  • 攻擊者可能在計算機運行期間（即使已啟用屏幕鎖定程序），獲取對設備的物理訪問權限，或者在計算機停止運行後的極短時間內，藉助相關資源實施冷啟動攻擊。
  • 政府機構不僅擁有輕易實施上述攻擊的資源，還可能通過各種脅迫手段強迫你交出密鑰或密碼短語。執法機構若懷疑你可能隱藏了某些可疑信息，這種行為可能是合法的。
  • 橡膠管密碼分析法（Rubber-hose cryptanalysis），即暴力威脅。另請參閱XKCD #538

為了抵禦能夠在你使用系統之前對其進行篡改的專業攻擊者，必須配置極高強度的磁碟加密方案（例如，具備完整性校驗且無明文引導分區的全系統加密）。即便如此，這也無法防範所有類型的篡改（例如硬體鍵盤記錄器）。最優的應對策略或許是基於硬體的全盤加密與可信計算。

警告：靜態數據加密也無法防止他人直接擦除你的磁碟。建議定期備份，以確保數據安全。

系統數據加密

雖然僅加密用戶數據本身（通常位於家目錄中，或在數據 DVD 等可移動媒體上）是最簡單且侵入性最小的方法，但是它有一些明顯的缺點。 在現代計算機系統中，有許多後台進程可能會在硬碟驅動器的非加密區域中緩存和存儲有關用戶數據或部分數據本身的信息，例如：

  • 交換分區（swap）
  • /tmp（用戶應用程式創建的臨時文件）
    • （可能的補救措施：避免此類應用程式；在ramdisk內掛載/tmp）
  • /var （日誌文件和資料庫等；例如，mlocate將所有文件名的索引存儲在/var/lib/mlocate/mlocate.db中)

解決辦法就是對系統和用戶數據都進行加密，阻止未經授權的對可能被系統緩存的隱私數據的物理訪問。不過，這樣也帶來了一個缺點——必須在啟動時對磁碟的加密部分進行解鎖。系統數據加密的另一個好處是，它給具有物理訪問權限的人安裝諸如鍵盤記錄器或 rootkits 之類的惡意軟體帶來了麻煩。

準備

選擇設置

根據你的目的（請閱讀上文#為什麼要使用加密？）及系統參數選取合適的加密設置。

此外，你需要回答下列問題：

你想抵禦什麼樣的「攻擊者」？
  • 在你的系統被關閉、被盜等情形下窺探你的磁碟的普通用戶
  • 可在你使用你的系統前後反覆獲得讀寫權限的專業密碼分析員
  • 任何介於這兩者之間的人
你想加密什麼？
  • 僅用戶數據
  • 用戶數據和系統數據
  • 僅機密數據，也就是你的數據的子集
交換分區（swap）、/tmp 等，應如何處理？
  • 禁用或掛載為 ramdisk
  • 被加密的交換分區
    • 將交換文件作為全盤加密的一部分
    • 單獨加密交換分區
應如何解鎖磁碟的加密部分？
  • 使用密碼
    • 同帳戶登錄密碼
    • 不同於帳戶登錄密碼
  • 使用密鑰文件（例如將其置於隨身攜帶的或保存在安全地方的U盤上）
  • 二者兼有
何時解鎖磁碟的加密部分？
  • 引導前
  • 引導過程中
  • 登錄帳戶時
  • 按需手動解鎖（帳戶登錄後）
應如何滿足多用戶需求？
  • 不需要
  • 使用每個用戶都知道的共享密碼（或密鑰文件）
  • 用於磁碟的同一加密部分的，被獨立分發的、可撤銷的密碼（或密鑰文件）
  • 為不同的用戶分配磁碟的加密部分

接下來你可以做出所需的技術選擇（參閱上文#可用方法，以及下文#加密是怎麼運作的），關於：

  • 塊設備加密與文件系統疊加加密的對比
  • 密鑰管理
  • 密碼及操作模式
  • 元數據存儲
  • 「下層目錄」的位置（在文件系統疊加加密的情況下）

準備磁碟

在一（部分）磁碟上設置加密之前，先考慮安全地擦除它。這包括用零字節或隨機字節的流覆蓋整個驅動器或分區，並且出於以下一個或兩個原因而做：

防止恢復以前存儲的數據

當文件系統創建或修改這些特定扇區所保存的數據時，磁碟加密不會改變單個扇區僅按需覆蓋的事實（請參閱下面的#加密是怎麼運作的。文件系統認為「當前未使用」的扇區不會被觸及，並且可能仍包含來自先前文件系統的數據殘餘。確保無法恢復之前存儲在驅動器上的所有數據的唯一方法是手動擦除它。 為此，使用零字節或隨機字節都沒有關係（儘管使用零字節擦除會快得多）。

防止洩露加密驅動器上的使用模式

理想情況下，磁碟的整個加密部分應該與均勻隨機數據無法區分。這樣，未經授權的人就無法知道哪些扇區以及多少個扇區實際上包含加密數據——這本身可能是一個理想的目標（作為真正機密性的一部分），也可以作為抵禦試圖破解加密的攻擊者的額外屏障。 為了實現這個目標，使用高質量隨機字節擦除磁碟至關重要。

第二個目標僅與塊設備加密結合使用才有意義，因為在文件系統疊加加密的情況下，無論如何都可以輕鬆定位加密數據（以獨特的加密文件的形式出現於宿主文件系統中）。另請注意，即使你只打算加密特定文件夾，如果你想刪除以前以未加密形式存儲在該文件夾中的文件，則必須擦除整個分區（由於磁碟碎片）。如果同一分區上還有其他文件夾，則必須備份它們，然後再將它們移回。

確定要執行哪種磁碟擦除後，請參閱文章安全地擦除磁碟以獲取技術說明。

提示：在決定使用哪種方法對硬碟驅動器進行安全擦除時，請記住，只要驅動器被用作加密驅動器，就不需要多次執行此操作。

可用方法

這篇文章的某些內容需要擴充。

原因：Ext4、ZFS，可能還有其他的文件系統，提供（原生（native））加密。 (在 Talk:靜態數據加密 中討論)

所有靜態數據加密方法都是這樣操作的：雖然磁碟實際存放的是加密數據，但只要加密容器（即磁碟中存放加密數據的邏輯部分）被「解鎖」並被掛載，那麼作業系統和應用程式就會把它 "看成 "相應的普通的可讀數據。

為此，用戶需要提供一些「機密信息」（通常採用密鑰文件和/或密碼短語的形式），從這些信息中可以派生出實際的加密密鑰（並在會話期間存儲在內核密鑰環中）。

如果你對這種操作完全不熟悉，還請閱讀下文#加密是怎麼運作的的部分。

可用的靜態數據加密方法可以按其操作層分為兩種類型：

棧式文件系統加密

作為堆疊在已有文件系統之上的層而實現的文件系統疊加加密方案，使所有寫入啟用加密的文件夾的文件在底層文件系統將其寫入磁碟之前就被即時加密，並在文件系統從磁碟讀取它們時被解密。這樣，文件以加密的形式存儲在宿主文件系統中（意味著它們的內容，通常還有它們的文件/文件夾名稱，都被長度大致相同的隨機數據所取代），但除此之外，它們仍然以正常的文件/符號連結/硬連結等形式存在於該文件系統中，如同沒有加密一樣。

它的實現方式是，為了解鎖宿主文件系統中存儲原始加密文件的文件夾（「下層目錄」），它被掛載（使用一個特殊的堆疊的偽文件系統）到它本身或可選的不同位置（「上層目錄」），然後相同的文件以可讀的形式出現——直到它再次被卸載，或系統被關閉。

此類別中可用的加密方案是eCryptfs和EncFS。

雲存儲優化

如果你正在部署文件系統疊加加密，以實現與第三方控制的位置(如雲存儲服務)的零知識同步（zero-knowledge synchronization），你可能需要考慮替代 eCryptfs 和 EncFS 的方案，因為他們並不是為了通過 Internet 傳輸文件這一目的而優化的。有一些解決方案是為了這個目的而設計的：

請注意，一些雲存儲服務直接通過他們自己的客戶端應用程式提供零知識加密（zero-knowledge encryption）。

塊設備加密

另者，塊設備加密（block device encryption）方法操作於文件系統層之下，確保寫入某個塊設備（即整個磁碟、分區或充當迴環設備的文件）的所有內容都是加密的。這意味著當塊設備處於脫機（offline）狀態時，它的整個內容看起來就像一大團隨機數據（a large blob of random data），無法確定它包含什麼樣的文件系統和數據。通過一種特殊方式將受保護的容器（在本例中為塊設備）掛載到任意位置，再次訪問數據。

Arch Linux 中提供了以下幾種「塊設備加密」方案：

loop-AES
loop-AES 是 cryptoloop 的繼任者，是一種安全、快速的系統加密解決方案。然而，loop-AES 被認為不如其他選擇易用（less user-friendly），因為它需要非標準內核支持（non-standard kernel support）。
dm-crypt
dm-crypt 是由 Linux 內核提供的標準設備映射器加密（standard device-mapper encryption）功能。喜歡全面掌握分區及密鑰管理的各個方面的人直接用它就行了。對 dm-crypt 的管理是通過 cryptsetup包 用戶空間實用程序完成的。它可用於以下類型的塊設備加密：LUKS（默認）、plain，並且具備有限的用於 loopAES 和 Truecrypt 設備的功能。
  • 默認情況下使用的 LUKS 是一個額外的便利層，它將 dm-crypt 所需的所有設置信息存儲在磁碟本身上，並抽象分區和密鑰管理，以提高易用性和加密安全性。
  • plain 模式下的 dm-crypt，作為原始的內核功能，並沒有採用便利層。用它來應用（與 LUKS 類型）同樣的加密強度是比較困難的。這樣做時，會產生更長的密碼或密鑰文件（二者被統稱為 keys）。但是，它具有其他優點，描述於下文#塊設備加密與文件系統疊加加密的對比[損壞的連結：無效的章節]之中。
TrueCrypt/VeraCrypt
一種可移植（portable）格式，支持整個磁碟/分區或文件容器的加密，兼容所有主流作業系統。對 TrueCrypt 的開發於2014年5月被其開發者停止。其分支 VeraCrypt 於2016年被審計。

關於選定的操作層的實際含義，參閱下文#塊設備加密與文件系統疊加加密的對比[損壞的連結：無效的章節]，以及對 eCryptfs的總體描述。參閱Category:Encryption，了解下表比較的方法的可用內容，以及未包括在表中的其他工具。

塊設備加密與文件系統疊加加密的對比

塊設備加密 原生/疊加式文件系統加密
加密 塊設備 文件
加密數據的容器可能是…… 磁碟、磁碟分區，或作為迴環設備使用的文件 現有文件系統中的目錄
與文件系統的關係 在文件系統層下運行：不關心加密塊設備的內容是文件系統、分區表、LVM 設置還是其他任何內容 通過文件系統原生功能，或向現有文件系統添加額外的疊加加密層來實現加密。兩者都會在文件寫入/讀取時自動加密/解密。，以在文件寫入或讀取時自動進行加密/解密
加密文件元數據（文件數、目錄結構、文件大小、權限、最後修改時間等） 是
（使用 'discard' 可能會暴露文件的大小） 		部分
（文件名會被加密，其他元數據是否可見取決於具體功能實現）
可被用於可用於定製加密整個硬碟（包括分區表）（包括分區表） 是 否
可被用於加密交換空間 是 否
可被用作加密數據容器而無需預先分配固定大小的加密數據容器 否
（使用 'discard' 可能允許稀疏分配的容器，代價是暴露文件的大小） 		是
可被用於保護無法直接訪問塊設備的現有文件系統，例如NFS 或 Samba 共享、雲存儲等 否1 是2
允許對加密文件進行允許對加密文件進行離線文件級備份 否 是
  1. 理論上在這些文件系統中，一個單獨的文件也可以被用作容器（通過虛擬迴環設備），但這樣實際上就不再是在使用該文件系統（以及它提供的功能）了。
  2. 對於 ZFS 不適用。對於其他文件系統原生加密方式，可能會存在掛載限制。

比較表

這篇文章的某些內容需要擴充。

原因：填寫空白處。為複選標記/交叉點添加來源。鹽值（salt）、密鑰槽擴散（key-slot diffusion）以及 密鑰擦除（key scrubbing）分別是什麼？ (在 Talk:靜態數據加密 中討論)

「dm-crypt +/- LUKS」 一欄表示 dm-crypt 在 LUKS（"+"）和 plain（"-"）加密模式下的功能。如果某個特定功能需要使用 LUKS，則以「（使用 LUKS）」表示。同樣，「（不使用 LUKS）」表示使用 LUKS 會阻礙實現該功能，應使用 plain 模式。

概要（Summary） Loop-AES dm-crypt +/- LUKS VeraCrypt ZFS fscrypt eCryptfs EncFS gocryptfs
加密類型 塊設備 塊設備 塊設備 原生文件系統或塊設備 原生文件系統 堆疊式文件系統 堆疊式文件系統 堆疊式文件系統
說明（Note） 存在時間最長的一種；可能是速度最快的；適用於舊系統 Linux 上塊設備加密的事實標準；非常靈活 TrueCrypt 的受維護分支，支持 TrueCrypt 和 VeraCrypt 卷 加密功能相對較新（2019 年）；通過 ZVOL 提供加密塊設備 Chrome OS 和 Android 加密的默認方案 比 EncFS 稍快；單個加密文件可在不同系統間移動 最容易使用的一種；支持非 root 用戶管理 EncFS 的潛在繼任者
在 Arch Linux 中的可用性 需要手動編譯、自定義內核 內核模塊：已隨默認內核提供；工具：device-mapper包、cryptsetup包 veracrypt包 ZFS#安裝 內核模塊：已隨默認內核提供；工具：fscrypt包 內核模塊：已隨默認內核提供；工具：ecryptfs-utils包 encfs包 gocryptfs包
許可證 GPL GPL Apache License 2.0，部分代碼受 TrueCrypt License v3.0 約束 CDDL GPL（內核）、Apache 2.0（用戶空間工具） GPL GPL MIT
加密實現 內核空間 內核空間 內核空間 內核空間 內核空間 用戶空間（FUSE） 用戶空間（FUSE） 用戶空間（FUSE）
加密元數據存儲 ？ 使用 LUKS：LUKS 標頭 （已解密）設備的開始/結束位置

(格式規範)

DSL（數據集和快照層；

演講/ 幻燈片)

每個文件系統根目錄中的 .fscrypt 目錄 每個加密文件的標頭 每個 EncFS 容器頂層的控制文件 ？
封裝後的加密密鑰存儲 ？ 使用 LUKS：LUKS 標頭 （已解密）設備的開始/結束位置

(格式規範)

DSL（數據集和快照層；

演講/ 幻燈片)

每個文件系統根目錄中的 .fscrypt 目錄 可存儲於任意位置的密鑰文件 可存儲於任意位置的密鑰文件

[1] [2]

？
可用功能（Usability features） Loop-AES dm-crypt +/- LUKS VeraCrypt ZFS fscrypt eCryptfs EncFS gocryptfs
非 root 用戶可以創建/銷毀加密數據容器 否 否 否 是 是 受限 是 是
提供GUI 否 否 是 否 否 否 是

可選

否
支持登錄時自動掛載 ？ 是 是

使用 systemd 和 /etc/crypttab

是

使用 systemd

是 是 是 是
支持在不活動時自動卸載 ？ ？ ？ 否 否 ？ 是 是

[3]

安全特性（Security features） Loop-AES dm-crypt +/- LUKS VeraCrypt ZFS fscrypt eCryptfs EncFS gocryptfs
支持的加密算法 AES AES、Anubis、CAST5/6、Twofish、Serpent、Camellia、Blowfish……（內核 Crypto API 提供的所有算法） AES、Twofish、Serpent、Camellia、Kuznyechik AES AES、ChaCha12 AES、Blowfish、Twofish…… AES、Blowfish、Twofish，以及系統中可用的其他密碼算法 AES
完整性保護（Integrity） 無 LUKS2 中可選 無 CCM、GCM 無 無（默認模式）
HMAC（paranoia 模式） 		無 GCM
支持加鹽 ？ 是
（使用 LUKS） 		是 是 是 是 ？ 是
支持級聯多個密碼算法 ？ 不支持在單個設備中級聯，但塊設備可以級聯 是

AES-Twofish、AES-Twofish-Serpent、Serpent-AES、Serpent-Twofish-AES、Twofish-Serpent

否 否 ？ 否 否
支持密鑰槽擴散（key-slot diffusion） ？ 是
（使用 LUKS） 		？ ？ 否 ？ ？ ？
防止密鑰擦除攻擊（key scrubbing） 是 是
（不使用 LUKS） 		？ ？ 否 ？ ？ ？
支持同一加密數據使用多個（可獨立撤銷的）密鑰 ？ 是
（使用 LUKS） 		？ 否 是 ？ 否 ？
性能特性（Performance features） Loop-AES dm-crypt +/- LUKS VeraCrypt ZFS fscrypt eCryptfs EncFS gocryptfs
多線程支持 ？ 是

[4]

是 是 是 ？ ？ 是
支持硬體加速加密 是 是 是 是 是 是 是

[5]

是
塊設備加密特有功能（Block device encryption specific） Loop-AES dm-crypt +/- LUKS VeraCrypt ZFS
支持（手動）就地調整加密塊設備大小 ？ 是 否 是
堆疊式文件系統加密特有功能（Stacked filesystem encryption specific） ZFS fscrypt eCryptfs EncFS gocryptfs
支持的文件系統 ZFS ext4、F2FS、UBIFS ext3、ext4、xfs（有注意事項）、jfs、nfs…… ext3、ext4、xfs（有注意事項）、jfs、nfs、cifs……

[6]

任意文件系統
可以加密文件名 是

[7]

是 是 是 是
可以不加密文件名 否 否 是 是 是

[8]

優化處理稀疏文件 是 是 否 是 是
兼容性與流行度（Compatibility & prevalence） Loop-AES dm-crypt +/- LUKS VeraCrypt ZFS fscrypt eCryptfs EncFS gocryptfs
支持的 Linux 內核版本 2.0 或更新版本 CBC 模式自 2.6.4 起支持，ESSIV 自 2.6.10 起支持，LRW 自 2.6.20 起支持，XTS 自 2.6.24 起支持 ？ 2.6.32 或更新版本（截至 0.8.3） 4.1 或更新版本 ？ 2.4 或更新版本 ？
加密數據也可以從 Windows 訪問 ？ ？ 是 是


OpenZFS on Windows (倉庫)

否 ？ 否


（需要管理員權限）

是


cppcryptfs 移植版

加密數據也可以從 Mac OS X 訪問 ？ ？ 是 是


OpenZFS on OS X (倉庫)

否 ？ 是

[9]

是

[10]
（測試版質量）

加密數據也可以從 FreeBSD 訪問 ？ ？ 是 是


ZFS on FreeBSD （原生； 倉庫）

否 ？ 是

[11]

否

[12]

應用於 ？ Debian/Ubuntu 安裝程序（系統加密）
Fedora 安裝程序 		？ ？ Android、Chrome OS ？ ？ ？

示例

在實踐中，結果可能是這樣的：

示例 1
僅利用用戶的家目錄（home directory）裡的一個被用 EncFS 加密的路徑名為 ~/Private 的虛擬文件夾的簡單的（內部硬碟驅動器）用戶數據加密
  • 被 on-disk 存儲的文件的加密版本位於 ~/.Private（encrypted versions of the files stored on-disk in ~/.Private）
  • 使用專用密碼按需解鎖
示例 2
部分系統加密，每個用戶的主目錄用 ECryptfs 加密
  • 使用帳戶登錄密碼，在各個用戶登錄時被解鎖
  • 具有用LUKS的dm-crypt加密的 swap 和 /tmp 分區，使用每個會話自動生成的一次性密鑰
  • 禁止 slocate（及類似的應用程式）索引或緩存 /home 的內容
示例 3
系統加密——具有用LUKS的dm-crypt加密的整個硬碟驅動器，/boot 分區除外（不過，用 GRUB 引導時，/boot 可被加密）
  • 使用密碼或帶有密鑰文件的 U 盤，在引導期間解鎖
  • 每個用戶可能有不同的密碼/密鑰——可獨立撤銷的
  • 可用 LUKS on LVM 實現跨驅動器加密或靈活性分區布局
示例 4
隱藏式/plain 系統加密——具有 plain dm-crypt 加密的整個硬碟驅動器
  • USB-boot，使用專用密碼 + 帶有密鑰文件的U盤
  • 在掛載前檢查數據完整性
  • /boot 分區位於上述U盤上
示例 5
文件容器加密——將預分配的文件用作用戶數據的加密容器

當然還有許多其他的組合。你應該仔細計劃什麼樣的設置適合你的系統。

加密是怎麼運作的

本節旨在作為對常規磁碟加密的核心設置的概念和過程的高級介紹。

它不涉及技術或數學細節（請查閱相應的文獻），但應該讓系統管理員大致了解不同的設置選擇（尤其是關於密鑰管理）如何影響可用性和安全性。

基本原則

出於磁碟加密的目的，每個塊設備（或文件系統疊加加密情況下的單個文件）被劃分為等長的扇區，例如 512 字節（4,096 位）。然後在每個扇區的基礎上進行加密/解密，因此磁碟上塊設備/文件的第 n 個扇區將存儲原始數據的第 n個扇區的加密版本。

每當作業系統或應用程式從塊設備/文件請求某個數據片段時，包含數據的整個扇區（或扇區們）將被從磁碟讀取，被即時解密，並被臨時存儲在內存中： 

           ╔═══════╗
  扇区 1   ║“？？？……”║
           ╠═══════╣         ╭┈┈┈╮
  扇区 2   ║“？？？……”║         ┊ 密钥 ┊
           ╠═══════╣         ╰┈┬┈╯
          :              :              │
           ╠═══════╣             ▼             ┣┉┉┉┉┉┉┉┫
  扇区 n   ║“？？？……”║━━━━━（解密）━━━━▶┋“甲乙丙……”┋   扇区 n
           ╠═══════╣                            ┣┉┉┉┉┉┉┉┫
          :              :
           ╚═══════╝

              磁盘上加密的                                RAM 中解密的数据
              块设备或文件

同樣，在每次寫入操作中，所有受影響的扇區都一定會被徹底地重加密（而其餘扇區不受影響）。

為了能夠對數據進行解密/加密，磁碟加密系統需要知道與之相關的唯一的秘密 "鑰匙"。每當要掛載相關的加密塊設備或文件夾時，必須提供與其相對應的密鑰（以下稱為「主密鑰」）。

密鑰的熵對於加密的安全性至關重要。一個隨機生成的一定長度的字節串，例如32位元組（256比特），雖具有所需的安全性，卻沒法記憶，也無法在掛載期間手動應用。

出於這個原因，有兩種技術被用作輔助手段。第一種是應用密碼學來增加主密鑰的熵值，通常涉及一個單獨的人類友好的口令。對於不同類型的加密，#比較表列出了各自的特點。第二種方法是創建一個具有高熵的密鑰文件，並將其存儲在與要加密的數據驅動器分開的介質上。

另請參閱維基百科：認證加密（英文頁面）。

密鑰、密鑰文件和密碼短語

以下是如何使用密鑰文件來存儲、加密保護主密鑰的示例：

存儲在明文密鑰文件中

簡直（以可讀形式）將主密鑰存儲在文件中是最簡單的選擇。該文件——被稱為「密鑰文件」——可以放置於你保存在安全位置的 U 盤上，並且僅在你想要掛載磁碟的加密部分時（例如在啟動或登錄期間）將它連接到計算機。

以受密碼保護的形式存儲在密鑰文件或磁碟本身中

主密鑰（以及加密數據）可以使用一段必須記下來且每次你想要掛載加密的塊設備或文件夾時都必須輸入的保密密碼短語（secret passphrase）進行保護。有關詳細信息，請參閱下面的#加密的元數據。

給每個會話隨機生成一個臨時的

在某些情況下，例如在加密交換空間（swap）或 /tmp 分區時，根本不需要保留永久的主密鑰。可以給每個會話隨機生成一個新的一次性密鑰，而無需任何用戶交互。這意味著一旦被卸載，寫入相關分區的所有文件都不能被任何人再次解密——在那些特定的用例中，這非常好。

加密的元數據

加密技術經常使用密碼函數來增強主密鑰本身的安全性。在掛載加密設備時，密碼或密鑰文件通過這些（密碼函數）傳遞，只有結果才能解鎖主密鑰以解密數據。

一個常見的設置是（通過一種「密鑰導出函數（key derivation function）」）對密碼短語（passphrase）應用所謂的「密鑰拉伸（key stretching）」，並使用生成的增強密碼短語作為掛載密鑰來解密（之前以加密的形式存儲的）實際的主密鑰： 

 ╭┈┈┈┈┈┈┈╮                           ╭┈┈┈┈┈╮
 ┊ 挂载密码短语 ┊━━━━⎛密钥导出⎞━━━▶┊ 挂载密钥 ┊
 ╰┈┈┈┈┈┈┈╯   ,──⎝  函数  ⎠        ╰┈┈┬┈┈╯
 ╭──╮          ╱                               │
 │ 盐 │────´                                  │
 ╰──╯                                           │
 ╭───────╮                                 ▼           ╭┈┈┈┈╮
 │ 加密的主密钥 │━━━━━━━━━━━━━━━（解密）━━━▶┊ 主密钥 ┊
 ╰───────╯                                              ╰┈┈┈┈╯

密鑰導出函數（如 PBKDF2 或 scrypt）刻意地放慢速度（它應用一個哈希函數的多次迭代，例如 HMAC-SHA-512 的 1000 次迭代），因此通過暴力破解來找到密碼短語變得不可行。對於認證用戶的正常用例，每個會話只需要計算一次，因此小的減速不是問題。 它（密鑰導出函數）還需要一個額外的數據塊，即所謂的「鹽」，作為一個參數——在設置磁碟加密期間隨機生成一次，並被作為加密元數據的一部分不受保護地存儲。因為每次設置的值都不同，攻擊者無法使用密鑰導出函數的預計算表來加速暴力破解。

加密的主密鑰可以與加密的數據一起存儲在磁碟上。這樣，加密數據的機密性完全取決於保密密碼短語。

可以通過將加密的主密鑰存儲在密鑰文件中來獲得額外的安全性，例如U 盤。這提供了雙重身份驗證(two-factor authentication)：現在訪問加密數據需要只有你知道的內容（密碼短語），以及只有你擁有的內容（密鑰文件）。

實現雙重身份驗證的另一種方法是增強上述密鑰檢索方案，以數學方式將密碼短語與從（位於U 盤或類似設備上的）一個或多個外部文件讀取的字節數據「結合」起來，然後將其傳遞給密鑰導出函數。任何文件都在考慮範圍之中，例如有助於#合理推諉[損壞的連結：無效的章節]的普通的JPEG圖像。不過，在這種情況下，它們仍然被稱為「密鑰文件」。

在其導出後，只要掛載了加密的塊設備或文件夾，主密鑰就會被安全地存儲在內存中（例如，在內核密鑰環中）。

不過，它通常不直接用於對磁碟數據進行加/解密。 例如，在文件系統疊加加密的情形中，每個文件都可以自動分配它自己的加密密鑰。每當文件要被讀取/修改時，這個文件密鑰首先需要用主密鑰進行解密，然後它本身才能用於對文件內容進行加/解密。 

                           ╭┈┈┈┈┈╮
                           ┊  主密钥  ┊
   磁盘上的文件：          ╰┈┈┬┈┈╯
  ┌──────────┐       │
  ╎╭────────╮╎       ▼         ╭┈┈┈┈┈╮
  ╎│ 加密的文件密钥 │━━━（解密）━━▶┊ 文件密钥 ┊
  ╎╰────────╯╎                  ╰┈┈┬┈┈╯
  ╎┌────────┐╎                        ▼          ┌┈┈┈┈┈┈┈┈┈┐
  ╎│ 加密的文件内容 │◀━━━━━━━━━━（加/解密）━━▶┊ 可读取的文件内容 ┊
  ╎└────────┘╎                                    └┈┈┈┈┈┈┈┈┈┘
  └──────────┘

以類似的方式，在文件系統疊加加密的情形下，可以使用單獨的密鑰（例如，每個文件夾一個）來加密文件名。

在塊設備加密的情況下，每個設備使用一個主密鑰，因此使用所有數據。一些方法提供了為同一設備分配多個密碼短語/密鑰文件的特性，而另一些方法則沒有。有些使用上述函數來保護主密鑰，有些則把密鑰安全的控制權完全交給用戶。通過 dm-crypt 在 plain 或 LUKS 模式下使用的加密參數解釋兩個例子。

當比較兩種模式使用的參數時，我們注意到 dm-crypt plain 模式有關於如何定位密鑰文件的參數（如--keyfile-size、--keyfile-offset）。dm-crypt LUKS 模式不需要這些，因為每個塊設備在開頭都包含一個帶有加密元數據的標頭。標頭包括使用的密碼、加密的主密鑰本身以及派生解密所需的參數。後面的參數又來自於主密鑰初始加密時使用的選項（如--iter-time、--use-random）。

對於不同技術的優/缺點，請參考#比較表或瀏覽特定頁面。

另請參閱：

密碼和操作模式

用於在相對於給定加密密鑰彼此對應的未加密和加密數據（所謂的「明文（plaintext）」和「密文（ciphertext）」）之間進行轉換的實際算法稱為「密碼（cipher）」。

磁碟加密採用「塊密碼（block cipher）」，它對固定長度的數據塊進行操作，例如16 字節（128 位）。在撰寫本文時，主要使用的是：

塊大小 密鑰大小 注釋
AES 128 bits 128、192 或 256 bits 經 NSA 批准用於保護「機密」和「絕密」機密的美國政府信息（當使用 192 或256位的密鑰大小時）
Blowfish 64 bits 32–448 bits 最早公開的無專利安全密碼之一，因此在 Linux上非常成熟
Twofish 128 bits 128、192 或 256 bits 作為 Blowfish的繼任者而開發，但尚未得到廣泛使用
Serpent 128 bits 128、192 或 256 bits 被認為是入圍AES決賽的五個算法中最安全的[13][14][15].

加/解密扇區（見上文[損壞的連結：無效的章節]）是通過將其劃分為與密碼的塊大小相匹配的小塊來實現的，並遵循特定的規則集（所謂的「操作模式（mode of operation）」）將密碼連續地應用於各個塊。

僅將其不加以修改地單獨應用於每個區塊（被稱為 "電子編碼本（electronic codebook，ECB）"模式）是不安全的。因為如果相同的 16 字節明文總會產生相同的16 字節密文，攻擊者可輕易識別出存儲在磁碟上的密文中的加密模式。

實踐中使用的最基本（且常見的）操作模式是「密碼分組連結（cipher-block chaining，CBC）」。使用此模式加密扇區時，每個明文數據塊以數學方式與前一個塊的密文組合，然後使用密碼對其進行加密。對於第一個塊，由於它之前沒有密文，因此使用了一個特殊的預生成的數據塊（data block），該數據塊與扇區的加密的元數據（cryptographic metadata）一起存儲，稱為「初始化向量 (initialization vector，IV)」： 

                                          ╭─────╮
                                          │初始化向量│
                                          ╰──┬──╯
           ╭  ╠═════╣       ╭─密钥    │      ┣┉┉┉┉┉┫
           │  ║          ║       ▼          ▼      ┋          ┋       . 开始
           ┴  ║"????????"║◀━（密码）━━━（+）━━┋"Hello, W"┋ 块  ╱╰──┐
        文件或 ║          ║                           ┋          ┋ 1   ╲╭──┘
      块设备的 ║          ║-─────────╮      ┋          ┋       '
      n 号扇区 ╟─────╢       ╭─密钥    │      ┠┉┉┉┉┉┨
           ┬  ║          ║       ▼          ▼      ┋          ┋
           │  ║"????????"║◀━（密码）━━━（+）━━┋"orld!!!!"┋ 块
           │  ║          ║                           ┋          ┋ 2 
           │  ║          ║-─────────╮      ┋          ┋
           │  ╟─────╢                   │      ┠┉┉┉┉┉┨
           │  ║          ║                   ▼      ┋          ┋
          :   :   ...   :        ...         ...     :   ...   :  ...

                磁盘上的密文                             RAM 中的明文

類似地，在解密時，程序是反過來的。

對應於每個扇區的唯一的初始化向量的生成是值得注意的。最簡單的選擇是把現成的數值（如扇區號碼）以某種可預見的方式計算。但這將給可以重複訪問系統的攻擊者執行所謂的水印攻擊以可乘之機。為了預防這種情況，可以使用一種稱為 「加密的鹽扇區初始化向量 （Encrypted salt-sector initialization vector，ESSIV）」的方法來生成初始化向量，使它們在潛在攻擊者看來完全隨機。

還有許多其他更複雜的操作模式可用於磁碟加密，它們已經提供了針對此類攻擊的內置安全性（因此不需要 ESSIV）。 有些還可以額外保證加密數據的真實性（即確認它沒有被無權訪問密鑰的人修改/損壞）。

另請參見：

流密碼

流密碼以數據流的方式工作，不需要「操作模式」這樣的概念。然而，磁碟加密所需的特性（例如「wide-block」）意味著需要在其基礎上添加額外層。就 Linux 系統上的磁碟加密而言，主要例子是 Adiantum 配置中的 XChaCha12，即 xchacha12,aes-adiantum，專為硬體不支持 AES 加速的低端系統設計。Adiantum 在此類硬體上運行速度快，並且能夠保證加密數據的真實性。

合理推諉

參見 Wikipedia:Plausible deniability.

用於磁碟加密場景的數據備份

為防止數據丟失，製作用戶數據的備份。一般來說，你的被加密數據的備份也應該加密。

塊設備加密

有多種選擇：你可以將加密容器（encryption container）所在的磁碟塊設備（disk block device）備份為映像（image），例如 /dev/sdx；也可以備份加密容器內的文件系統，例如 /dev/mapper/dm_name；亦可備份裡面的文件，例如使用 rsync。 以下部分列出了每個選項的優點和缺點。

磁碟塊設備備份

磁碟塊設備備份會：

  • 按原樣加密，具有與工作副本（working copy）相同的安全級別
  • 包含你的 LUKS 標頭
  • 總是和磁碟塊設備一樣大
  • 難以使用高級備份策略，例如增量備份、壓縮或重複數據刪除
  • 易於恢復到新磁碟因其亦恢復加密容器

文件系統或文件備份

文件系統或文件備份，它：

  • 不按原樣加密
  • 應在通過網絡傳輸之前或保存到磁碟時進行加密。需做額外的工作
  • 未必具有與工作副本相同的安全級別
  • 不包含你的LUKS標頭
  • 僅與文件系統上的已用空間一樣大，比如看看partclone
  • 可使用高級備份策略，例如增量備份、壓縮或重複數據刪除
  • 需要手動將加密容器恢復到新磁碟，例如通過恢復 LUKS 標頭的備份

LUKS 標頭備份

如果使用 LUKS，則可以對 LUKS 標頭進行備份：定期檢查與同步這些備份是有意義的，尤其是在密碼已被撤銷的情況下。

但是，如果你有數據備份，並且想要恢復它，你可以使用 cryptsetup 從頭開始重新創建 LUKS 加密分區，然後恢復數據，因此備份 LUKS 標頭不如備份數據重要。