静态数据加密
本文讨论了静态数据加密软件,该软件可以即时加密/解密写入/读取自块设备、磁盘分区或目录的数据。块设备的例子包括硬盘驱动器、闪存驱动器和 DVD。
静态数据加密应仅被视为操作系统现有安全机制的辅助手段 - 专注于保护物理访问安全,同时依赖系统其他部分来提供诸如网络安全和基于用户的访问控制等功能。
为什么要使用加密?
静态数据加密确保文件始终以加密形式存储在磁盘上。只有当系统正在运行并由受信任的用户解锁时,文件才能以可读形式提供给操作系统和应用程序(使用中或传输中的数据)。未经授权的人直接查看磁盘内容,只会找到乱码般的随机数据,而不是实际的文件。
例如,当计算机或硬盘驱动器在以下情况下,这可以防止未经授权查看数据:
- 位于非信任人员可能在你离开时获得访问权限的地方
- 丢失或被盗,例如笔记本电脑、上网本或外部存储设备
- 在维修店
- 在其寿命结束后被丢弃
此外,静态数据加密还可以用于增加针对未经授权尝试篡改操作系统的安全性——例如,攻击者在你离开时可以物理访问系统,从而安装键盘记录器或特洛伊木马。
您仍然容易受到以下威胁:
一个非常强大的磁盘加密设置(例如,具有真实性检查且没有明文引导分区的全系统加密)是抵抗专业攻击者的机会,这些攻击者能够在您使用系统之前篡改您的系统。即使这样,它也无法阻止所有类型的篡改(例如硬件键盘记录器)。最好的补救措施可能是基于硬件的全盘加密和可信计算。
系统数据加密
虽然仅加密用户数据本身(通常位于主目录中,或在诸如数据 DVD 之类的可移动介质上)是最简单且侵入性最小的方法,但它有一些明显的缺点。在现代计算机系统中,许多后台进程可能会缓存和存储有关用户数据或数据本身部分的信息在硬盘驱动器的非加密区域中,例如
解决方案是同时加密系统数据和用户数据,防止未经授权的物理访问可能被系统缓存的私人数据。然而,这带来的缺点是,磁盘加密部分的解锁必须在启动时发生。系统数据加密的另一个好处是,对于具有物理访问权限的人来说,它使安装恶意软件(如 键盘记录器 或 rootkit)变得复杂。
准备工作
选择设置
哪种加密设置适合您将取决于您的目标(请阅读上面的 #为什么要使用加密?)和系统参数。
除此之外,您还需要回答以下问题
- 您想要防范哪种“攻击者”?
- 当您的系统关闭、被盗等时,随意窥探您磁盘的普通计算机用户。
- 专业密码分析师,他们可以在您使用系统之前和之后重复获得对您系统的读/写访问权限
- 介于两者之间的任何人
- 您想加密什么?
- 仅用户数据
- 用户数据和系统数据
- 仅机密数据,即您数据的一个子集
- 应该如何处理交换分区、
/tmp
等?
- 禁用或挂载为内存盘
- 加密交换分区
- 作为全盘加密一部分的交换文件
- 单独加密交换分区
- 应该如何解锁磁盘的加密部分?
- 密码
- 与登录密码相同
- 与登录密码不同
- 密钥文件(例如在 USB 闪存盘上,您将其保存在安全的地方或随身携带)
- 两者都
- 何时应该解锁磁盘的加密部分?
- 启动前
- 启动期间
- 登录时
- 手动按需 (登录后)
- 应该如何容纳多个用户?
- 完全不
- 使用每个用户都知道的共享密码(或密钥文件)
- 为磁盘的同一加密部分独立颁发和可撤销的密码(或密钥文件)
- 为不同的用户分隔磁盘的加密部分
然后您可以继续做出所需的技术选择(请参阅下面的 #可用方法 和 #加密如何工作),关于
- 堆叠文件系统加密 vs. 块设备加密
- 密钥管理
- 密码和操作模式
- 元数据存储
- “较低目录”的位置(在堆叠文件系统加密的情况下)
准备磁盘
在磁盘(或磁盘的一部分)上设置加密之前,请考虑先安全地擦除它。这包括用零字节或随机字节流覆盖整个驱动器或分区,并且这样做是出于以下一个或两个原因
- 防止恢复以前存储的数据
磁盘加密不会改变以下事实:只有在文件系统创建或修改这些特定扇区保存的数据时,才会按需覆盖各个扇区(请参阅下面的 #加密如何工作)。文件系统认为“当前未使用”的扇区不会被触及,并且可能仍然包含来自以前文件系统的数据残余。确保先前存储在驱动器上的所有数据都无法被恢复的唯一方法是手动擦除它。为此目的,使用零字节还是随机字节并不重要(尽管用零字节擦除会快得多)。
- 防止泄露加密驱动器上的使用模式
理想情况下,磁盘的整个加密部分应与均匀随机数据无法区分。这样,任何未经授权的人都无法知道哪些扇区以及有多少扇区实际包含加密数据 - 这本身可能是一个理想的目标(作为真正机密性的一部分),并且还可以作为对抗试图破解加密的攻击者的额外屏障。为了实现此目标,使用高质量随机字节擦除磁盘至关重要。
第二个目标仅在与块设备加密结合使用时才有意义,因为在堆叠文件系统加密的情况下,无论如何都可以轻松定位加密数据(以主机文件系统中不同加密文件的形式)。另请注意,即使您只想加密特定文件夹,如果您想摆脱以前以未加密形式存储在该文件夹中的文件(由于磁盘碎片),您也必须擦除整个分区。如果同一分区上有其他文件夹,则必须备份它们并在之后移回它们。
一旦您决定要执行哪种磁盘擦除,请参阅 安全擦除磁盘 文章以获取技术说明。
可用方法
所有静态数据加密方法都以这样一种方式运行:即使磁盘实际上保存的是加密数据,只要密码容器(即磁盘上保存加密数据的逻辑部分)已被“解锁”和挂载,操作系统和应用程序“看到”的仍然是相应的正常可读数据。
为了实现这一点,需要用户提供一些“秘密信息”(通常以密钥文件和/或密码短语的形式),从中可以导出实际的加密密钥(并存储在内核密钥环中,直到会话结束)。
如果您完全不熟悉此类操作,请同时阅读下面的 #加密工作原理 部分。
可用的静态数据加密方法可以按其操作层级分为两种类型
堆叠式文件系统加密
堆叠式文件系统加密解决方案被实现为一个层,它堆叠在现有文件系统之上,导致写入启用加密的文件夹的所有文件在底层文件系统将它们写入磁盘之前进行即时加密,并在文件系统从磁盘读取它们时进行解密。 这样,文件以加密形式存储在主机文件系统中(这意味着它们的内容,通常还有它们的文件/文件夹名称,都被长度大致相同的随机数据替换),但除此之外,它们仍然像没有加密一样存在于该文件系统中,作为普通文件/符号链接/硬链接/等等。
它的实现方式是,为了解锁主机文件系统中存储原始加密文件的文件夹(“下层目录”),它被挂载(使用特殊的堆叠式伪文件系统)到自身或可选的不同位置(“上层目录”),在这些位置,相同的文件然后以可读形式出现 - 直到它再次被卸载,或系统关闭。
此类别中的可用解决方案包括 eCryptfs 和 EncFS,或以下云就绪选项之一。
云存储优化
如果您正在部署堆叠式文件系统加密以实现与第三方控制的位置(如云存储服务)的零知识同步,您可能需要考虑 eCryptfs 和 EncFS 的替代方案,因为这些方案并未针对通过互联网传输文件进行优化。 相反,有一些解决方案是为此目的而设计的
- gocryptfs
- cryptomatorAUR 或 cryptomator-binAUR (多平台)
- cryfs
请注意,某些云存储服务直接通过其自身的 客户端应用程序 提供零知识加密。
块设备加密
另一方面,块设备加密方法在文件系统层之下运行,并确保写入特定块设备(即整个磁盘、分区或充当 环回设备 的文件)的所有内容都被加密。 这意味着当块设备离线时,它的全部内容看起来像一大块随机数据,无法确定它包含的文件系统和数据的类型。 访问数据再次通过以特殊方式将受保护的容器(在本例中为块设备)挂载到任意位置来完成。
以下“块设备加密”解决方案在 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 |
---|---|---|---|---|---|---|---|---|
加密类型 | 块设备 | 块设备 | 块设备 | 原生文件系统或块设备 | 原生文件系统 | 堆叠式文件系统 | 堆叠式文件系统 | 堆叠式文件系统 |
注意 | 存在时间最长的;可能最快的;可在旧系统上工作 | 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) |
密码元数据存储在... | ? | 使用 LUKS:LUKS 标头 | (解密)设备的开始/结束处(格式规范) | DSL(数据集和快照层;演讲/幻灯片) | 每个文件系统根目录下的 .fscrypt 目录 |
每个加密文件的标头 | 每个 EncFS 容器顶层的控制文件 | ? |
封装的加密密钥存储在... | ? | 使用 LUKS:LUKS 标头 | (解密)设备的开始/结束处(格式规范) | DSL(数据集和快照层;演讲/幻灯片) | 每个文件系统根目录下的 .fscrypt 目录 |
可以存储在任何地方的密钥文件 | 可以存储在任何地方的密钥文件 | ? |
可用性功能 | Loop-AES | dm-crypt +/- LUKS | VeraCrypt | ZFS | fscrypt | eCryptfs | EncFS | gocryptfs |
非 root 用户可以创建/销毁加密数据的容器 | 否 | 否 | 否 | 是 | 是 | 有限 | 是 | 是 |
提供 GUI | 否 | 否 | 是 | 否 | 否 | 否 | 是 | 否 |
支持登录时自动挂载 | ? | 是 | 是 | 使用 systemd 是 | 是 | 是 | 是 | 是 |
支持在不活动时自动卸载 | ? | ? | ? | 否 | 否 | ? | 是 | 是 [3] |
安全功能 | 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 |
完整性 | 无 | LUKS2 中可选 | 无 | CCM、GCM | 无 | 无 | 无(默认模式) HMAC(偏执模式) |
GCM |
支持加盐 | ? | 是 (使用 LUKS) |
是 | 是 | 是 | 是 | ? | 是 |
支持级联多个密码 | ? | 不在一个设备中,但块设备可以级联 | 是 AES-Twofish、AES-Twofish-Serpent、Serpent-AES、Serpent-Twofish-AES、Twofish-Serpent |
否 | 否 | ? | 否 | 否 |
支持密钥槽扩散 | ? | 是 (使用 LUKS) |
? | ? | 否 | ? | ? | ? |
防止密钥擦除的保护 | 是 | 是 (不使用 LUKS) |
? | ? | 否 | ? | ? | ? |
支持同一加密数据的多个(可独立撤销的)密钥 | ? | 是 (使用 LUKS) |
? | 否 | 是 | ? | 否 | ? |
性能特点 | Loop-AES | dm-crypt +/- LUKS | VeraCrypt | ZFS | fscrypt | eCryptfs | EncFS | gocryptfs |
多线程支持 | ? | 是 [4] |
是 | 是 | 是 | ? | ? | 是 |
硬件加速加密支持 | 是 | 是 | 是 | 是 | 是 | 是 | 是 [5] |
是 |
块设备加密特定 | Loop-AES | dm-crypt +/- LUKS | VeraCrypt | ZFS | ||||
支持(手动)就地调整加密块设备的大小 | ? | 是 | 否 | 是 | ||||
堆叠式文件系统加密特定 | ZFS | fscrypt | eCryptfs | EncFS | gocryptfs | |||
支持的文件系统 | ZFS | ext4、F2FS、UBIFS | ext3、ext4、xfs(有注意事项)、jfs、nfs... | ext3、ext4、xfs(有注意事项)、jfs、nfs、cifs... | 任何 | |||
是否能够加密文件名 | 是 zfs(8) |
是 | 是 | 是 | 是 | |||
是否能够不加密文件名 | 否 | 否 | 是 | 是 | 是 [7] | |||
优化的稀疏文件处理 | 是 | 是 | 否 | 是 | 是 | |||
兼容性与普及性 | 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 访问 | ? | ? | 是 | 是 Windows 上的 OpenZFS(仓库) |
否 | ? | 否(需要管理员权限) | 是(cppcryptfs 端口) |
加密数据也可以从 Mac OS X 访问 | ? | ? | 是 | 是 OS X 上的 OpenZFS(仓库) |
否 | ? | 是 [8][死链接 2024-07-30 ⓘ] |
是(beta 质量) |
加密数据也可以从 FreeBSD 访问 | ? | ? | 是 | 是 FreeBSD 上的 ZFS(原生;仓库) |
否 | ? | 是 [9] |
? |
使用者 | ? | Debian/Ubuntu 安装程序(系统加密) Fedora 安装程序 |
? | ? | Android、Chrome OS | ? | ? | ? |
示例
在实践中,它可能变成这样
- 示例 1
- 简单的用户数据加密(内部硬盘驱动器),使用用户主目录中名为
~/Private
的虚拟文件夹,并使用 EncFS 加密- 文件的加密版本存储在磁盘上的
~/.Private
中 - 按需使用专用密码短语解锁
- 文件的加密版本存储在磁盘上的
- 示例 2
- 部分系统加密,每个用户的主目录都使用 ECryptfs 加密
- 在相应的用户登录时使用登录密码短语解锁
swap
和/tmp
分区使用 Dm-crypt with LUKS 加密,使用自动生成的每个会话的临时密钥- 禁用 slocate(和类似应用程序)对
/home
内容的索引/缓存。
- 示例 3
- 系统加密 - 除
/boot
分区之外的整个硬盘驱动器(但是,/boot
可以使用 GRUB 加密)使用 Dm-crypt with LUKS 加密- 在启动期间使用密码短语或带有密钥文件的 USB 驱动器解锁
- 每个用户可能有不同的密码短语/密钥 - 可独立撤销
- 可能使用 LUKS on LVM 实现跨多个驱动器的加密或分区布局灵活性
- 示例 4
- 隐藏/plain 系统加密 - 使用 plain dm-crypt 加密整个硬盘驱动器
- USB 启动,使用专用密码短语和带有密钥文件的 USB 驱动器
- 在挂载之前检查数据完整性
/boot
分区位于上述 USB 驱动器上
- 示例 5
- 文件容器加密 - 预分配的文件用作用户数据的加密容器
- 诸如
~/.volume.img
之类的文件使用 Dm-crypt/Encrypting a non-root file system#File container 加密 - 通过将整个容器复制到远程主机进行偶尔备份
- 诸如
当然,还有许多其他可能的组合。 您应该仔细计划哪种设置适合您的系统。
加密工作原理
本节旨在对常用磁盘加密设置核心的概念和过程进行高级介绍。
它不涉及技术或数学细节(请查阅相关文献),但应为系统管理员提供对不同设置选择(尤其是在密钥管理方面)如何影响可用性和安全性的粗略理解。
基本原理
出于磁盘加密的目的,每个块设备(或堆叠文件系统加密情况下的单个文件)都被划分为等长的扇区,例如 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
同样,在每次写入操作时,所有受影响的扇区都必须完全重新加密(而其余扇区保持不变)。
为了能够解密/加密数据,磁盘加密系统需要知道与其关联的唯一密钥“secret key”。每当要挂载加密的块设备或文件夹时,必须提供其对应的密钥(以下称为“主密钥”)。
密钥的熵对于加密的安全性至关重要。例如,一个特定长度的随机生成的字节字符串,例如 32 字节(256 位),具有所需的属性,但不便于记忆和在挂载期间手动应用。
因此,使用了两种辅助技术。第一种是应用密码学来增加主密钥的熵属性,通常涉及一个单独的、对人类友好的密码短语。对于不同类型的加密,#比较表列出了各自的特性。第二种方法是创建一个具有高熵的密钥文件,并将其存储在与要加密的数据驱动器分离的介质上。
另请参阅 维基百科:认证加密。
密钥、密钥文件和密码短语
以下是如何使用密钥文件存储和密码学安全地保护主密钥的示例
- 存储在明文密钥文件中
简单地将主密钥存储在文件(以可读形式)中是最简单的选择。该文件 - 称为“密钥文件” - 可以放置在 USB 闪存驱动器上,您将其保存在安全的位置,并且仅在要挂载磁盘的加密部分时(例如,在启动或登录期间)连接到计算机。
- 以密码短语保护的形式存储在密钥文件或磁盘本身上
主密钥(以及由此加密的数据)可以用秘密密码短语保护,您每次想要挂载加密的块设备或文件夹时都必须记住并输入该密码短语。有关详细信息,请参阅下面的 #加密元数据。
- 为每个会话即时随机生成
在某些情况下,例如,当加密交换空间或 /tmp
分区时,完全没有必要保留持久的主密钥。可以为每个会话随机生成一个新的临时密钥,而无需任何用户交互。这意味着一旦卸载,写入该分区的所有文件将永远无法被任何人解密 - 这在那些特定的用例中是完全可以接受的。
加密元数据
加密技术经常使用加密函数来增强主密钥本身的安全性。在挂载加密设备时,密码短语或密钥文件会通过这些函数,只有结果才能解锁主密钥以解密数据。
一种常见的设置是对密码短语应用所谓的“密钥拉伸”(通过“密钥派生函数”),并将由此产生的增强密码短语用作挂载密钥,以解密实际的主密钥(该主密钥先前已以加密形式存储)。
╭┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈╮ ╭┈┈┈┈┈┈┈┈┈┈┈╮ ┊ mount passphrase ┊━━━━⎛key derivation⎞━━━━▶┊ mount key ┊ ╰┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈╯ ,──⎝ function ⎠ ╰┈┈┈┈┈┬┈┈┈┈┈╯ ╭──────╮ ╱ │ │ salt │───────────´ │ ╰──────╯ │ ╭──────────────────────╮ ▼ ╭┈┈┈┈┈┈┈┈┈┈┈┈╮ │ encrypted master key │━━━━━━━━━━━━━━━━━━━━(decryption)━━━━▶┊ master key ┊ ╰──────────────────────╯ ╰┈┈┈┈┈┈┈┈┈┈┈┈╯
密钥派生函数(例如 PBKDF2 或 scrypt)被故意设计得很慢(它应用哈希函数的多次迭代,例如 HMAC-SHA-512 的 1000 次迭代),以便暴力破解攻击以查找密码短语变得不可行。对于授权用户的正常用例,每个会话只需要计算一次,因此小的减速不是问题。它还需要一个额外的数据 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 在 plain 或 LUKS 模式下使用的加密参数解释了两个示例。
当比较两种模式使用的参数时,人们注意到 dm-crypt plain 模式具有与如何定位密钥文件相关的参数(例如 --keyfile-size
、--keyfile-offset
)。dm-crypt LUKS 模式不需要这些,因为每个块设备都在开头包含一个带有加密元数据的标头。标头包括使用的密码、加密的主密钥本身以及解密所需的派生参数。后者的参数又来自于主密钥初始加密期间使用的选项(例如 --iter-time
、--use-random
)。
有关不同技术的优缺点,请参考 #比较表 或浏览特定页面。
另请参阅
密码和操作模式
用于在未加密和加密数据片段(所谓的“明文”和“密文”)之间进行转换的实际算法,它们在给定的加密密钥方面彼此对应,被称为“密码”。
磁盘加密采用“块密码”,它对固定长度的数据块进行操作,例如 16 字节(128 位)。在撰写本文时,主要使用的块密码是
块大小 | 密钥大小 | 注释 | |
---|---|---|---|
AES | 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)。有些还可以额外保证加密数据的真实性(即确认它没有被没有密钥访问权限的人修改/损坏)。
另请参阅
可否认性
请参阅 维基百科:可否认性 和 维基百科:可否认加密。
磁盘加密场景的备份
制作用户数据的备份以防止数据丢失。通常,您的加密数据的备份也应该进行加密。
块设备加密
有多种选择;您可以将加密容器所在的磁盘块设备备份为映像,例如 /dev/sdx
,或者您可以备份加密容器内的文件系统,例如 /dev/mapper/dm_name
,或者您可以备份文件,例如使用 rsync。以下部分列出了每种选择的优点和缺点。
磁盘块设备的备份
磁盘块设备的备份是
- 以与工作副本相同的安全级别进行加密
- 包含您的 LUKS 标头
- 始终与磁盘块设备一样大
- 不容易实现高级备份策略,例如增量备份、压缩或重复数据删除
- 易于恢复到新磁盘,因为这也恢复了加密容器
文件系统或文件的备份
文件系统或文件的备份是
- 不像工作副本那样进行加密
- 在通过网络传输或保存到磁盘时应进行加密,需要额外的努力
- 不一定以与工作副本相同的安全级别进行加密
- 不包含您的 LUKS 标头
- 仅与文件系统上已用空间一样大,例如,请参阅 partclone
- 允许高级备份策略,例如增量备份、压缩或重复数据删除
- 需要手动将加密容器恢复到新磁盘,例如通过恢复 LUKS 标头备份
LUKS 标头备份
如果使用 LUKS,则可以制作 LUKS 标头的备份:定期检查和同步这些备份可能是有意义的,特别是如果密码短语已被撤销。
但是,如果您有数据备份,并且想要恢复它,您可以从头开始使用 cryptsetup 重新创建 LUKS 加密分区,然后恢复数据,因此备份 LUKS 标头不如备份数据重要。