数据静态加密
本文讨论了数据静态 加密软件，它可以即时加密/解密写入/读取自块设备、磁盘分区或目录的数据。块设备的例子包括硬盘驱动器、闪存驱动器和 DVD。
数据静态加密应仅被视为操作系统现有安全机制的补充 - 专注于保护物理访问，同时依赖系统的其他部分来提供网络安全和基于用户的访问控制等功能。
为何使用加密？
数据静态加密确保文件始终以加密形式存储在磁盘上。只有当系统正在运行并被受信任用户解锁时，文件才以可读形式提供给操作系统和应用程序（使用中或传输中的数据）。未经授权的人直接查看磁盘内容，只会发现乱码般的随机数据，而不是实际文件。
例如，这可以防止在以下情况下未经授权查看数据：计算机或硬盘
- 位于非信任人员可能在你离开时获得访问权限的地方
- 丢失或被盗，如笔记本电脑、上网本或外部存储设备
- 在维修店
- 在其生命周期结束后被丢弃
此外，数据静态加密还可用于增加针对未经授权尝试篡改操作系统的安全性——例如，攻击者可以在你离开时获得对系统的物理访问权限，从而安装键盘记录器或特洛伊木马。
你仍然容易受到以下攻击：
一个非常强大的磁盘加密设置（例如，具有真实性检查且没有明文启动分区的完整系统加密）是抵御专业攻击者的必要条件，这些攻击者能够在你使用系统之前篡改你的系统。即使那样，它也无法阻止所有类型的篡改（例如硬件键盘记录器）。最好的补救措施可能是基于硬件的完整磁盘加密和可信计算。
系统数据加密
虽然仅加密用户数据本身（通常位于主目录中，或在数据 DVD 等可移动媒体上）是最简单且侵入性最小的方法，但它有一些明显的缺点。在现代计算机系统中，许多后台进程可能会在硬盘驱动器的非加密区域（如：
解决方案是同时加密系统和用户数据，防止未经授权的物理访问可能被系统缓存的私有数据。然而，这样做带来的缺点是必须在启动时解锁磁盘的加密部分。系统数据加密的另一个好处是，对于具有物理访问权限的人来说，它会使安装恶意软件（如 键盘记录器 或 rootkit）变得更加复杂。
准备工作
选择设置
哪种加密设置适合你将取决于你的目标（请阅读上面的#为何使用加密？）和系统参数。
在其他事项中，你需要回答以下问题：
- 你想防范哪种“攻击者”？
- 当你的系统关闭、被盗等时，随意的计算机用户窥探你的磁盘
- 专业的密码分析师，他们可以在你使用系统之前和之后反复读取/写入你的系统
- 介于两者之间的任何人
- 你想加密什么？
- 仅用户数据
- 用户数据和系统数据
- 仅机密数据，即你的数据子集
- 应该如何处理交换分区、
/tmp等？
- 禁用或挂载为内存盘
- 加密交换分区
- 作为完整磁盘加密一部分的交换文件
- 单独加密交换分区
- 应该如何解锁磁盘的加密部分？
- 密码短语
- 与登录密码相同
- 与登录密码不同
- 密钥文件（例如在 U 盘上，你将其保存在安全的地方或随身携带）
- 两者兼有
- 何时应该解锁磁盘的加密部分？
- 启动前
- 启动期间
- 登录时
- 手动按需 （登录后）
- 应该如何容纳多个用户？
- 完全不考虑
- 使用每个用户都知道的共享密码短语（或密钥文件）
- 为磁盘的同一加密部分独立颁发和可撤销的密码短语（或密钥文件）
- 为不同用户分隔开的磁盘加密部分
然后你可以继续做出所需的技术选择（参见下面的#可用方法和#加密如何工作），关于：
- 堆叠文件系统加密与块设备加密
- 密钥管理
- 密码和操作模式
- 元数据存储
- “下层目录”的位置（在堆叠文件系统加密的情况下）
准备磁盘
在（部分）磁盘上设置加密之前，请考虑先安全地擦除它。这包括用零字节流或随机字节覆盖整个驱动器或分区，这样做是出于以下一个或两个原因：
- 防止恢复以前存储的数据
磁盘加密不会改变以下事实：只有在文件系统创建或修改这些特定扇区保存的数据时，才会按需覆盖各个扇区（参见下面的#加密如何工作）。文件系统认为“当前未使用”的扇区不会被触及，并且可能仍然包含以前文件系统的数据残余。确保无法恢复你以前存储在驱动器上的所有数据的唯一方法是手动擦除它。为此，使用零字节还是随机字节并不重要（尽管用零字节擦除会快得多）。
- 防止泄露加密驱动器上的使用模式
理想情况下，磁盘的整个加密部分应与完全随机的数据无法区分。这样，未经授权的人员就无法知道哪些扇区以及多少扇区实际包含加密数据 - 这本身可能是一个理想的目标（作为真正机密性的一部分），并且还可以作为对抗试图破解加密的攻击者的额外屏障。为了实现此目标，使用高质量随机字节擦除磁盘至关重要。
第二个目标仅在与块设备加密结合使用时才有意义，因为在堆叠文件系统加密的情况下，无论如何都可以轻松定位加密数据（以主机文件系统中不同的加密文件形式）。另请注意，即使你只想加密特定文件夹，如果你想摆脱以前以未加密形式存储在该文件夹中的文件（由于磁盘碎片），你也将不得不擦除整个分区。如果同一分区上有其他文件夹，你将不得不备份它们并在之后移回它们。
一旦你决定要执行哪种磁盘擦除，请参阅安全擦除磁盘文章以获取技术说明。
可用方法
所有数据静态加密方法都以这样一种方式运行：即使磁盘实际上保存的是加密数据，操作系统和应用程序也“看到”它是相应的正常可读数据，只要加密容器（即磁盘的逻辑部分，保存加密数据）已“解锁”和挂载。
为了实现这一点，用户需要提供一些“秘密信息”（通常以密钥文件和/或密码短语的形式），从中可以派生出实际的加密密钥（并存储在内核密钥环中，在会话期间）。
如果你完全不熟悉此类操作，请也阅读下面的#加密如何工作部分。
可用的数据静态加密方法可以按其操作层分为两种类型：
堆叠文件系统加密
堆叠文件系统加密解决方案被实现为一个层，该层堆叠在现有文件系统之上，导致写入启用加密的文件夹的所有文件在底层文件系统将它们写入磁盘之前即时加密，并在文件系统从磁盘读取它们时解密。这样，文件以加密形式存储在主机文件系统中（意味着它们的内容，通常还有它们的文件/文件夹名称，都被替换为长度大致相同的随机数据），但除此之外，它们仍然像没有加密一样存在于该文件系统中，作为普通文件/符号链接/硬链接/等等。
其实现方式是，要解锁主机文件系统中存储原始加密文件的文件夹（“下层目录”），它被挂载（使用特殊的堆叠伪文件系统）到自身或可选的不同位置（“上层目录”），在其中，相同的文件然后以可读形式出现 - 直到再次卸载或系统关闭。
此类别中的可用解决方案包括 eCryptfs 和 EncFS，或以下云就绪选项之一。
云存储优化
如果你正在部署堆叠文件系统加密以实现与第三方控制的位置（如云存储服务）的零知识同步，你可能需要考虑 eCryptfs 和 EncFS 的替代方案，因为这些方案未针对通过互联网传输文件进行优化。相反，有一些为此目的设计的解决方案：
- gocryptfs
- cryptomatorAUR 或 cryptomator-binAUR (多平台)
- cryfs
请注意，一些云存储服务直接通过他们自己的客户端应用程序提供零知识加密。
块设备加密
另一方面，块设备加密方法在文件系统层之下运行，并确保写入特定块设备（即整个磁盘、分区或充当环回设备的文件）的所有内容都被加密。这意味着当块设备离线时，其整个内容看起来像一个大的随机数据 blob，无法确定它包含哪种文件系统和数据。访问数据再次通过以特殊方式将受保护的容器（在本例中为块设备）挂载到任意位置来完成。
以下“块设备加密”解决方案在 Arch Linux 中可用：
- loop-AES
- loop-AES 是 cryptoloop 的后代，是系统加密的安全快速解决方案。但是，loop-AES 被认为不如其他选项用户友好，因为它需要非标准的内核支持。
- dm-crypt
- dm-crypt 是 Linux 内核提供的标准设备映射器加密功能。喜欢完全控制分区和密钥管理的所有方面的人可以直接使用它。dm-crypt 的管理是通过 cryptsetup 用户空间实用程序完成的。它可用于以下类型的块设备加密：LUKS（默认）、plain，并且对 loopAES 和 Truecrypt 设备具有有限的功能。
- 默认情况下使用的 LUKS 是一个额外的便利层，它将 dm-crypt 所需的所有设置信息存储在磁盘本身上，并抽象出分区和密钥管理，以尝试提高易用性和加密安全性。
- plain dm-crypt 模式是原始内核功能，不使用便利层。使用它更难以应用相同的加密强度。这样做时，会产生更长的密钥（密码短语或密钥文件）。然而，对于非常特定的情况，它具有其他优点。例如，可以对单个块设备进行分段并相应地加密。
- TrueCrypt/VeraCrypt
- 一种可移植格式，支持加密整个磁盘/分区或文件容器，并在所有主要操作系统之间具有兼容性。TrueCrypt 于 2014 年 5 月被其开发人员停止维护。VeraCrypt 分支在 2016 年进行了审核。
有关所选操作层的实际影响，请参阅下面的#块设备加密与堆叠文件系统加密的比较，以及 eCryptfs 的一般说明。请参阅Category:Encryption 以获取下面比较的方法的可用内容，以及表中未包含的其他工具。
块设备加密与堆叠文件系统加密的比较
| 块设备加密 | 原生/堆叠文件系统加密 | |
|---|---|---|
| 加密 | 块设备 | 文件 |
| 加密数据的容器可以是... | 磁盘或磁盘分区 / 作为环回设备的文件 | 现有文件系统中的目录 |
| 与文件系统的关系 | 在文件系统层下运行：不关心加密块设备的内容是文件系统、分区表、LVM 设置还是其他任何内容 | 通过文件系统原生功能或现有文件系统的附加/堆叠加密层添加加密。两者都在写入/读取文件时自动加密/解密文件。 |
| 加密文件元数据（文件数、目录结构、文件大小、权限、修改时间等） | 是 （使用“discard”可能会泄露文件大小） |
部分 （文件名已加密，其他元数据可能可见，具体取决于功能） |
| 可用于自定义加密整个硬盘驱动器（包括分区表） | 是 | 否 |
| 可用于加密交换空间 | 是 | 否 |
| 可以在不为加密数据容器预先分配固定空间量的情况下使用 | 否 （使用“discard”可能允许稀疏分配容器，但会以泄露文件大小为代价） |
是 |
| 可用于保护现有文件系统，而无需块设备访问，例如 NFS 或 Samba 共享、云存储等。 | 否1 | 是2 |
| 允许加密文件的离线文件备份 | 否 | 是 |
- 嗯，这些文件系统中的单个文件可以用作容器（虚拟环回设备！）但那样一来，实际上就不再使用文件系统（及其提供的功能）了。
- ZFS 不可以。对于其他文件系统原生加密，挂载限制可能适用。
比较表
“dm-crypt +/- LUKS”列表示 dm-crypt 对于 LUKS（“+”）和 plain（“-”）加密模式的功能。如果特定功能需要使用 LUKS，则用“（使用 LUKS）”表示。同样，“（不使用 LUKS）”表示使用 LUKS 对于实现该功能会适得其反，应使用 plain 模式。
| 总结 | Loop-AES | dm-crypt +/- LUKS | VeraCrypt | ZFS | fscrypt | eCryptfs | EncFS | gocryptfs |
|---|---|---|---|---|---|---|---|---|
| VeraCrypt | fscrypt | fscrypt | fscrypt | eCryptfs | EncFS | 加密类型 | 加密类型 | 加密类型 |
| 块设备 | 原生文件系统或块设备 | 原生文件系统 | 块设备 | 堆叠文件系统 | 堆叠文件系统 | 堆叠文件系统 | 注意 | 存在时间最长；可能最快；适用于旧系统 |
| Linux 上块设备加密的事实标准；非常灵活 | TrueCrypt 的维护分支，支持 TrueCrypt 和 VeraCrypt 卷 | 加密功能相对较新 (2019)；ZVOL 提供加密块设备 | Chrome 操作系统和 Android 加密的默认设置 | 比 EncFS 稍快；单个加密文件可在系统之间移植 | 最容易使用；支持非 root 管理 | EncFS 的有抱负的继任者 | 在 Arch Linux 中的可用性 | gocryptfs |
| 需要手动编译的自定义内核 | 内核模块： 已随默认内核一起提供；工具： device-mapper, cryptsetup | 内核模块： 已随默认内核一起提供；工具： device-mapper, cryptsetup | veracrypt | ZFS#安装 | 内核模块： 已随默认内核一起提供；工具： fscrypt | 内核模块： 已随默认内核一起提供；工具： device-mapper, cryptsetup | 内核模块： 已随默认内核一起提供；工具： device-mapper, cryptsetup | 内核模块： 已随默认内核一起提供；工具： ecryptfs-utils |
| encfs | 许可证 | 许可证 | 许可证 | 许可证 | 许可证 | 许可证 | GPL | GPL |
| GPL | ? | Apache License 2.0，部分受 TrueCrypt License v3.0 约束 | CDDL | GPL (内核), Apache 2.0 (用户空间工具) | GPL | MIT | 加密在 ... 中实现 | ? |
| 内核空间 | ? | 内核空间 | CDDL | GPL (内核), Apache 2.0 (用户空间工具) | GPL | 内核空间 | 内核空间 | ? |
| 用户空间 (FUSE) | Loop-AES | 用户空间 (FUSE) | VeraCrypt | ZFS | fscrypt | eCryptfs | EncFS | gocryptfs |
| 用户空间 (FUSE) | 否 | 否 | 否 | 是 | 是 | 加密元数据存储在 ... 中 | 是 | 是 |
| 环回设备 | 否 | 否 | 是 | 否 | 否 | 否 | 是 | 否 |
| DSL（数据集和快照层；演讲/幻灯片） | ? | 是 | 是
|
每个加密文件的标头 | 是 | 是 | 是 | 是 |
| 每个 EncFS 容器顶层的控制文件 | ? | ? | ? | 否 | 否 | ? | 是 | 是 [3] |
| 包装的加密密钥存储在 ... 中 | Loop-AES | 用户空间 (FUSE) | VeraCrypt | ZFS | fscrypt | eCryptfs | EncFS | gocryptfs |
| 环回设备 | 使用 LUKS：LUKS 标头 | 密钥文件，可以存储在任何位置 | 用户友好性功能 | 使用 LUKS：LUKS 标头 | 命令行 | dm-crypt +/- LUKS | GUI (可选) | 使用 LUKS：LUKS 标头 |
| GUI | 命令行 | 命令行 | 命令行 | 非 root 用户可以创建/销毁加密数据的容器 | 命令行 | 命令行 | 有限 是 |
是 |
| 是 | ? | 是 是 |
是 | 是 | 是 | 是 | ? | 是 |
| 提供 GUI | ? | 可选 | 是 是 |
否 | 否 | ? | 否 | 否 |
| 是 | ? | 是 是 |
? | ? | 否 | ? | ? | ? |
| 是 | 是 | 是 支持登录时自动挂载 |
? | ? | 否 | ? | ? | ? |
| 通过 systemd 和 /etc/crypttab | ? | 是 是 |
? | 否 | 是 | ? | 否 | ? |
| 通过 systemd 是 | Loop-AES | 用户空间 (FUSE) | VeraCrypt | ZFS | fscrypt | eCryptfs | EncFS | gocryptfs |
| 是 | ? | 是 [4] |
是 | 是 | 是 | ? | ? | 是 |
| 是 | 是 | 是 | 是 | 是 | 是 | 是 | 是 [5] |
是 |
| 是 | Loop-AES | 用户空间 (FUSE) | VeraCrypt | ZFS | ||||
| 支持在不活动时自动卸载 | ? | 是 | 否 | 是 | ||||
| 是 | ZFS | fscrypt | eCryptfs | EncFS | gocryptfs | |||
| 安全功能 | ZFS | 支持的密码 | AES | AES, Anubis, CAST5/6, Twofish, Serpent, Camellia, Blowfish,…（内核 Crypto API 提供的每个密码） | AES, Twofish, Serpent, Camellia, Kuznyechik | |||
| AES, ChaCha12 | 是 AES, Blowfish, Twofish... |
是 | 是 | 是 | 是 | |||
| AES, Blowfish, Twofish, 以及系统上可用的任何其他密码 | 否 | 否 | 是 | 是 | 是 [7] | |||
| 完整性 | 是 | 是 | 否 | 是 | 是 | |||
| 无 | Loop-AES | 用户空间 (FUSE) | VeraCrypt | ZFS | fscrypt | eCryptfs | EncFS | gocryptfs |
| LUKS2 中可选 | CCM, GCM | 无（默认模式） | ? | HMAC (偏执模式) | GCM | ? | GCM | ? |
| GCM | ? | ? | 是 | 是 支持加盐 |
否 | ? | 否 (需要管理员权限) | 是 (cppcryptfs 端口) |
| 加密数据也可以从 Mac OS X 访问 | ? | ? | 是 | 是 OpenZFS on OS X (仓库) |
否 | ? | 是 [8][死链 2024-07-30 ⓘ] |
是 (beta 质量) |
| 加密数据也可以从 FreeBSD 访问 | ? | ? | 是 | 是 ZFS on FreeBSD (原生; 仓库) |
否 | ? | 是 [9] |
? |
| 用于 | ? | Debian/Ubuntu 安装程序 (系统加密) Fedora 安装程序 |
? | ? | Android, Chrome OS | ? | ? | ? |
示例
在实践中，它可能变成这样
- 示例 1
- 简单的用户数据加密 (内部硬盘驱动器)，使用名为
~/Private的虚拟文件夹，在用户主目录中使用 EncFS 加密- 文件的加密版本存储在磁盘上的
~/.Private中 - 使用专用密码按需解锁
- 文件的加密版本存储在磁盘上的
- 示例 2
- 部分系统加密，每个用户的主目录都使用 ECryptfs 加密
- 在各自用户登录时使用登录密码解锁
swap和/tmp分区使用 带有 LUKS 的 Dm-crypt 加密，使用自动生成的每会话一次性密钥- 禁用 slocate (和类似应用程序) 对
/home内容的索引/缓存。
- 示例 3
- 系统加密 - 除
/boot分区之外的整个硬盘驱动器 (但是，/boot可以使用 GRUB 加密) 使用 带有 LUKS 的 Dm-crypt 加密- 在启动期间使用密码或带有密钥文件的 USB 闪存盘解锁
- 可能每个用户使用不同的密码/密钥 - 可独立撤销
- 可能使用 LUKS on LVM 实现跨多个驱动器或分区布局灵活性的加密
- 示例 4
- 隐藏/普通系统加密 - 使用 普通 dm-crypt 加密整个硬盘驱动器
- USB 启动，使用专用密码和带有密钥文件的 USB 闪存盘
- 在挂载前检查数据完整性
/boot分区位于上述 USB 闪存盘上
- 示例 5
- 文件容器加密 - 一个预先分配的文件用作用户数据的加密容器
- 诸如
~/.volume.img之类的文件使用 Dm-crypt/加密非根文件系统#文件容器 加密 - 通过将整个容器复制到远程主机进行偶尔备份
- 诸如
当然，还有许多其他组合是可能的。 您应该仔细计划哪种设置适合您的系统。
加密如何工作
本节旨在对常用磁盘加密设置的核心概念和流程进行高层次的介绍。
它不涉及技术或数学细节 (请查阅相关文献)，但应为系统管理员提供对不同设置选择 (尤其是在密钥管理方面) 如何影响可用性和安全性的粗略理解。
基本原理
出于磁盘加密的目的，每个块设备 (或堆叠文件系统加密情况下的单个文件) 都被划分为等长的扇区，例如 512 字节 (4096 位)。 然后，加密/解密按扇区进行，因此磁盘上块设备/文件的第 n 个扇区将存储原始数据的第 n 个扇区的加密版本。
每当操作系统或应用程序请求块设备/文件中的某个数据片段时，将从磁盘读取包含该数据的整个扇区 (或多个扇区)，进行即时解密，并临时存储在内存中
╔═══════╗
sector 1 ║"???.."║
╠═══════╣ ╭┈┈┈┈┈╮
sector 2 ║"???.."║ ┊ key ┊
╠═══════╣ ╰┈┈┬┈┈╯
: : │
╠═══════╣ ▼ ┣┉┉┉┉┉┉┉┫
sector n ║"???.."║━━━━━━(decryption)━━━━━━━▶┋"abc.."┋ sector n
╠═══════╣ ┣┉┉┉┉┉┉┉┫
: :
╚═══════╝
encrypted unencrypted
blockdevice or data in RAM
file on disk
同样，在每次写入操作时，所有受影响的扇区都必须完全重新加密 (而其余扇区保持不变)。
为了能够解密/加密数据，磁盘加密系统需要知道与其关联的唯一密钥。 每当要挂载有问题的加密块设备或文件夹时，必须提供其相应的密钥 (以下称为“主密钥”)。
密钥的熵对于加密的安全性至关重要。 随机生成的特定长度的字节字符串，例如 32 字节 (256 位)，具有所需的属性，但不便于记忆和在挂载期间手动应用。
因此，使用了两种技术作为辅助手段。 第一种是应用密码学来增加主密钥的熵属性，通常涉及单独的易于人类记忆的密码。 对于不同类型的加密，#比较表 列出了各自的功能。 第二种方法是创建一个具有高熵的密钥文件，并将其存储在与要加密的数据驱动器分离的介质上。
另请参阅 Wikipedia:认证加密。
密钥、密钥文件和密码
以下是如何使用密钥文件存储和密码学安全地保护主密钥的示例
- 存储在纯文本密钥文件中
简单地将主密钥存储在文件 (以可读形式) 中是最简单的选择。 该文件 (称为“密钥文件”) 可以放置在 USB 闪存盘上，您可以将其保存在安全位置，并且仅在要挂载磁盘的加密部分时 (例如在启动或登录期间) 连接到计算机。
- 以受密码保护的形式存储在密钥文件或磁盘本身上
主密钥 (以及加密数据) 可以使用秘密密码进行保护，您必须记住该密码并在每次要挂载加密块设备或文件夹时输入。 有关详细信息，请参见 #加密元数据。
- 为每个会话即时随机生成
在某些情况下，例如在加密交换空间或 /tmp 分区时，完全没有必要保留持久性主密钥。 可以为每个会话随机生成一个新的临时密钥，而无需任何用户交互。 这意味着一旦卸载，写入到有问题的分区的所有文件将永远无法被任何人解密 - 这在那些特定的用例中是完全可以接受的。
加密元数据
加密技术经常使用密码学函数来增强主密钥本身的安全性。 在挂载加密设备时，密码或密钥文件会通过这些函数，只有结果才能解锁主密钥以解密数据。
一种常见的设置是对密码应用所谓的“密钥拉伸” (通过“密钥派生函数”)，并将生成的增强密码用作挂载密钥，用于解密实际的主密钥 (该主密钥先前已以加密形式存储)
╭┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈╮ ╭┈┈┈┈┈┈┈┈┈┈┈╮ ┊ mount passphrase ┊━━━━⎛key derivation⎞━━━━▶┊ mount key ┊ ╰┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈╯ ,──⎝ function ⎠ ╰┈┈┈┈┈┬┈┈┈┈┈╯ ╭──────╮ ╱ │ │ salt │───────────´ │ ╰──────╯ │ ╭──────────────────────╮ ▼ ╭┈┈┈┈┈┈┈┈┈┈┈┈╮ │ encrypted master key │━━━━━━━━━━━━━━━━━━━━(decryption)━━━━▶┊ master key ┊ ╰──────────────────────╯ ╰┈┈┈┈┈┈┈┈┈┈┈┈╯
密钥派生函数 (例如 PBKDF2 或 scrypt) 是故意慢的 (它应用哈希函数的多次迭代，例如 1000 次 HMAC-SHA-512 的迭代)，以便暴力破解密码以找到密码变得不可行。 对于授权用户的正常用例，它只需要在每个会话计算一次，因此小的减速不是问题。 它还需要一个额外的数据 blob，即所谓的“盐”作为参数 - 这在磁盘加密设置期间随机生成一次，并作为加密元数据的一部分不受保护地存储。 因为对于每个设置，它将是一个不同的值，这使得攻击者无法使用密钥派生函数的预计算表来加速暴力破解攻击。
加密的主密钥可以与加密数据一起存储在磁盘上。 这样，加密数据的机密性完全取决于秘密密码。
可以通过将加密的主密钥存储在例如 USB 闪存盘上的密钥文件中来获得额外的安全性。 这提供了双因素身份验证：现在访问加密数据需要一些只有您知道的东西 (密码)，以及另外一些只有您拥有的东西 (密钥文件)。
实现双因素身份验证的另一种方法是在数学上“组合”密码与从一个或多个外部文件 (位于 USB 闪存盘或类似设备上) 读取的字节数据，然后将其传递给密钥派生函数，从而增强上述密钥检索方案。 有问题的的文件可以是任何东西，例如普通的 JPEG 图像，这对于 #合理否认 可能是有益的。 然而，在这种情况下，它们仍然被称为“密钥文件”。
在派生之后，主密钥安全地存储在内存中 (例如在内核密钥环中)，只要加密的块设备或文件夹已挂载。
但是，它通常不直接用于解密/加密磁盘数据。 例如，在堆叠文件系统加密的情况下，可以自动为每个文件分配其自己的加密密钥。 每当要读取/修改文件时，首先需要使用主密钥解密此文件密钥，然后才能将其自身用于解密/加密文件内容
╭┈┈┈┈┈┈┈┈┈┈┈┈╮
┊ master key ┊
file on disk: ╰┈┈┈┈┈┬┈┈┈┈┈┈╯
┌ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┐ │
╎╭───────────────────╮╎ ▼ ╭┈┈┈┈┈┈┈┈┈┈╮
╎│ encrypted file key│━━━(decryption)━━━━▶┊ file key ┊
╎╰───────────────────╯╎ ╰┈┈┈┈┬┈┈┈┈┈╯
╎┌───────────────────┐╎ ▼ ┌┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┐
╎│ encrypted file │◀━━━━━━━━━━━━━━━(de/encryption)━━━━━▶┊ readable file ┊
╎│ contents │╎ ┊ contents ┊
╎└───────────────────┘╎ └┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┘
└ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┘
以类似的方式，在堆叠文件系统加密的情况下，可以使用单独的密钥 (例如，每个文件夹一个) 来加密文件名。
在块设备加密的情况下，每个设备使用一个主密钥，因此所有数据都使用一个主密钥。 有些方法提供为同一设备分配多个密码/密钥文件的功能，而另一些方法则不提供。 一些方法使用上述功能来保护主密钥，而另一些方法则将密钥安全性的控制权完全交给用户。 dm-crypt 在普通或 LUKS 模式下使用的加密参数解释了两个示例。
当比较两种模式使用的参数时，人们注意到 dm-crypt 普通模式具有与如何定位密钥文件相关的参数 (例如 --keyfile-size, --keyfile-offset)。 dm-crypt LUKS 模式不需要这些，因为每个块设备都包含一个头部，其中包含位于开头的加密元数据。 头部包括使用的密码、加密的主密钥本身以及解密所需的参数。 后者参数反过来又来自主密钥的初始加密期间使用的选项 (例如 --iter-time, --use-random)。
有关不同技术的优/缺点，请参考回 #比较表 或浏览特定页面。
另请参阅
- Security#Passwords
- Wikipedia:Passphrase
- Wikipedia:Key (cryptography)
- Wikipedia:Key management
- Wikipedia:Key derivation function
密码和操作模式
用于在未加密和加密数据片段 (分别称为“明文”和“密文”) 之间进行转换的实际算法，这些片段相对于给定的加密密钥相互对应，称为“密码”。
磁盘加密采用“块密码”，它在固定长度的数据块上运行，例如 16 字节 (128 位)。 在撰写本文时，主要使用的密码是
| 块大小 | 密钥大小 | 注释 | |
|---|---|---|---|
| 使用 LUKS：LUKS 标头 | 128 位 | 128、192 或 256 位 | 经 NSA 批准用于保护“机密”和“绝密”级美国政府信息 (当使用 192 或 256 位的密钥大小时) |
| Blowfish | 64 位 | 32–448 位 | 首批公开提供的无专利安全密码之一，因此在 Linux 上非常成熟 |
| Twofish | 128 位 | 128、192 或 256 位 | 开发为 Blowfish 的后继者，但尚未获得如此广泛的使用 |
| Serpent | 128 位 | 128、192 或 256 位 | 被认为是五个 AES 竞赛决赛中最安全的[10][11][12]。 |
加密/解密扇区 (见上文) 是通过将其划分为与密码块大小匹配的小块，并遵循一定的规则集 (所谓的“操作模式”) 来连续地将密码应用于各个块来实现的。
简单地将其单独应用于每个块而不进行修改 (称为“电子密码本 (ECB)”模式) 将是不安全的，因为如果相同的 16 字节明文始终产生相同的 16 字节密文，则攻击者可以轻松识别存储在磁盘上的密文中的模式。
实践中使用的最基本 (和最常见) 的操作模式是“密码块链接 (CBC)”。 当使用此模式加密扇区时，每个明文数据块都以数学方式与前一个块的密文组合，然后再使用密码对其进行加密。 对于第一个块，由于它没有先前的密文可以使用，因此使用了与扇区的加密元数据一起存储的特殊预生成数据块，称为“初始化向量 (IV)”
╭──────────────╮
│initialization│
│vector │
╰────────┬─────╯
╭ ╠══════════╣ ╭─key │ ┣┉┉┉┉┉┉┉┉┉┉┫
│ ║ ║ ▼ ▼ ┋ ┋ . START
┴ ║"????????"║◀━━━(cipher)━━━━━(+)━━━━━┋"Hello, W"┋ block ╱╰────┐
sector n ║ ║ ┋ ┋ 1 ╲╭────┘
of file or ║ ║──────────────────╮ ┋ ┋ '
blockdevice ╟──────────╢ ╭─key │ ┠┈┈┈┈┈┈┈┈┈┈┨
┬ ║ ║ ▼ ▼ ┋ ┋
│ ║"????????"║◀━━━(cipher)━━━━━(+)━━━━━┋"orld !!!"┋ block
│ ║ ║ ┋ ┋ 2
│ ║ ║──────────────────╮ ┋ ┋
│ ╟──────────╢ │ ┠┈┈┈┈┈┈┈┈┈┈┨
│ ║ ║ ▼ ┋ ┋
: : ... : ... ... : ... : ...
ciphertext plaintext
on disk in RAM
解密时，过程类似地反向进行。
值得注意的一件事是为每个扇区生成唯一的初始化向量。 最简单的选择是以可预测的方式从容易获得的值 (例如扇区号) 计算它。 但是，这可能允许具有重复系统访问权限的攻击者执行所谓的 水印攻击。 为了防止这种情况，可以使用一种称为“加密盐扇区初始化向量 (ESSIV)”的方法来生成初始化向量，使其对于潜在的攻击者而言看起来完全是随机的。
还有许多其他更复杂的操作模式可用于磁盘加密，这些模式已经提供了针对此类攻击的内置安全性 (因此不需要 ESSIV)。 有些还可以另外保证加密数据的真实性 (即确认它没有被没有密钥访问权限的人修改/损坏)。
另请参阅
合理否认
请参阅 Wikipedia:合理否认 和 Wikipedia:可否认加密。
磁盘加密场景的备份
制作用户数据的备份以防止数据丢失。 通常，您的加密数据的备份也应该被加密。
块设备加密
有多种选择； 您可以将加密容器所在的磁盘块设备备份为映像，例如 /dev/sdx，或者您可以备份加密容器内的文件系统，例如 /dev/mapper/dm_name，或者您可以备份文件，例如使用 rsync。 以下部分列出了每种选择的优点和缺点。
磁盘块设备的备份
磁盘块设备的备份是
- 像工作副本一样加密，具有相同的安全级别
- 包含您的 LUKS 标头
- 始终与磁盘块设备一样大
- 不容易允许高级备份策略，例如增量备份、压缩或重复数据删除
- 易于恢复到新磁盘，因为这也恢复了加密容器
文件系统或文件的备份
文件系统或文件的备份是
- 不像这样加密
- 在通过网络传输或保存到磁盘时应进行加密，这需要额外的努力
- 不一定与工作副本具有相同的安全级别进行加密
- 不包含您的 LUKS 标头
- 仅与文件系统上的已用空间一样大，请参阅例如 partclone
- 允许高级备份策略，例如增量备份、压缩或重复数据删除
- 需要手动将加密容器恢复到新磁盘，例如通过恢复 LUKS 标头备份
LUKS 标头备份
如果使用 LUKS，则可以制作 LUKS 标头的备份：定期检查和同步这些备份可能是有意义的，尤其是在密码已被撤销的情况下。
但是，如果您有数据备份并且想要恢复它，则可以使用 cryptsetup 从头开始重新创建 LUKS 加密分区，然后恢复数据，因此备份 LUKS 标头不如备份数据重要。