eCryptfs:堆叠式加密文件系统

作者:Mike Halcrow

媒体一直在不断报道政府和企业设施丢失或被盗的笔记本电脑、备份磁带、硬盘驱动器和服务器事件。这些设备通常包含医疗、金融和其他敏感数据。当存储设备落入坏人之手时,攻击者可以直接访问数据,完全绕过组织网络中已有的访问控制机制。报告表明,数百万人已经受到此类泄露事件的影响。因此,客户和公民面临身份欺诈和隐私泄露的风险日益增加。

尽管保护数据机密性的加密技术已经存在数十年,但许多组织未能将这项技术整合到他们处理敏感数据的流程中。在流程中包含加密的情况下,它通常是侵入式的、成本高昂且复杂的。组织有时会忽略建立数据加密策略,而员工在策略到位后也常常忽视这些策略。

在员工尝试使用加密的情况下,他们常常使用效果不佳。例如,他们经常选择弱密钥,并且很容易通过不安全的媒体(例如 Web 电子邮件或 USB 闪存驱动器)无意中以未加密的形式保存或传输数据。依赖于各个应用程序执行自身加密的安全策略,在用户将敏感信息复制并粘贴到其他不具备加密功能的应用程序时,通常会失效。

数据加密需要做到无处不在、透明、灵活、易于部署、集成到数据处理流程中,当然,还要足够安全以对抗复杂的攻击。无论访问数据的特定应用程序是什么,这些属性都需要有效。为了使加密服务与应用程序无关,操作系统内核本身应该为写入辅助存储的敏感信息提供系统范围的数据加密服务。

流行的加密文件系统解决方案

Linux 下存在几种文件系统加密选项,各有优缺点。设备映射器加密 (dm-crypt) 随 Linux 内核一起提供,并在块设备层提供加密。Loop-AES 和 TrueCrypt 必须从官方 Linux 内核单独获取,它们也在块设备层提供加密。使用块设备层加密,用户在块设备上创建文件系统,加密层在将数据写入实际的底层块设备之前透明地加密数据。

块设备层加密的主要优点是概念和实现都很简单。块设备层加密的另一个优点是,攻击者除非拥有密钥,否则无法了解文件系统的任何信息;例如,攻击者甚至不知道文件系统的类型或目录结构。在加密块设备上的文件系统中,可以安全有效地支持稀疏文件。

块设备加密可能存在缺点,这些缺点源于与文件系统本身缺乏集成

  • 必须为整个文件系统预先分配固定的存储区域。以后调整分区大小通常是一个不方便的过程。

  • 更改加密密钥或密码可能很困难。

  • 块设备加密机制无法灵活地使用不同的密钥或密码来加密不同的文件。

  • 增量备份实用程序等应用程序需要访问未加密的数据。

  • 文件系统中的所有内容都会产生加密和解密的开销,包括不需要保密的数据。

  • 文件在通过其他介质传输之前,必须使用用户空间应用程序重新加密。

EncFS 是一个用户空间加密文件系统,通过 FUSE 运行。用户空间文件系统比内核原生文件系统更容易实现,并且它们具有能够轻松利用用户空间库的优势。这使得开发人员能够以更少的时间和精力轻松实现功能丰富的文件系统。与块设备加密解决方案不同,EncFS 作为一个实际的文件系统运行。EncFS 加密和解密单个文件。基于 FUSE 的用户空间文件系统的缺点包括频繁的内核/用户空间上下文切换带来的性能开销,以及当前缺乏对共享可写内存映射的支持。

eCryptfs

eCryptfs 是一个用于 Linux 的内核原生堆叠式加密文件系统。堆叠式文件系统层叠在已挂载的现有文件系统之上,这些文件系统被称为底层文件系统。eCryptfs 是一个堆叠式文件系统,它在文件写入或读取底层文件系统时加密和解密文件。

用户空间中的应用程序发出文件系统系统调用,这些调用会通过内核虚拟文件系统 (VFS)。eCryptfs 和底层文件系统(例如,ext3、JFS、NFS 等)都在内核 VFS 中注册。eCryptfs 挂载点下的操作首先转到 eCryptfs。eCryptfs 从用户会话密钥环检索密钥材料,并使用内核加密 API 对文件内容执行加密和解密。eCryptfs 可能会向用户空间 eCryptfs 守护进程 (ecryptfsd) 发出密钥管理请求。eCryptfs 读取和写入存储在底层文件系统文件中的加密内容(图 1)。

eCryptfs: a Stacked Cryptographic Filesystem

图 1. 应用程序文件操作通过 eCryptfs 进行。

应用程序文件操作通过 eCryptfs 进行,eCryptfs 与内核加密 API、内核密钥环和用户空间 eCryptfs 守护进程通信,以执行加密和解密。eCryptfs 操作底层文件系统(如 JFS 或 ext3)中的文件。

eCryptfs 旨在提供类似于优秀隐私密码协议 (PGP) 应用程序的灵活性,作为一个透明的内核服务。因此,OpenPGP (RFC 2440) 规范启发了 eCryptfs 中的基本密钥处理技术。这包括在执行加密操作时使用密钥层次结构的常用过程(图 2)。

eCryptfs: a Stacked Cryptographic Filesystem

图 2. eCryptfs 加密和解密各个数据区。

eCryptfs 使用唯一的随机生成的“文件加密密钥”(FEK) 加密和解密每个文件中的各个数据区。FEK 使用“文件加密密钥加密密钥”(FEKEK) 加密,生成的“加密文件加密密钥”(EFEK) 存储在每个底层文件的标头中。

加密元数据位于加密底层文件的标头区域中。用户可以将底层文件按原样传输给其他用户,接收者可以通过 eCryptfs 访问文件的解密内容,只要他们拥有正确的密钥即可。这为如何处理文件提供了高度的灵活性,同时保持了强大的安全性。

使用 eCryptfs

eCryptfs 需要内核组件和用户空间组件。内核组件随当前主线 Linux 内核一起发布。请参阅列表 1,了解启用 eCryptfs 所需的最低内核选项。默认情况下,eCryptfs 使用 AES 密码。如果您构建了内核中的其他密码,eCryptfs 可以使用这些密码。

列表 1. eCryptfs 所需的内核选项

Code maturity level options  --->
  [*] Prompt for development and/or
      incomplete code/drivers

Security options  --->
  <M> Enable access key retention support

Cryptographic options  --->
  <M>   MD5 digest algorithm
  <M>   AES cipher algorithms

File systems  --->
  Miscellaneous filesystems  --->
    <M> eCrypt filesystem layer support (EXPERIMENTAL)

较新版本的 Linux 内核包含功能更丰富的 eCryptfs 版本。例如,Linux 内核版本 2.6.19 是第一个包含 eCryptfs 的官方内核版本,并且该内核中仅提供密码短语操作模式。在撰写本文时,开发内核分支版本 2.6.20-mm 包含公钥支持,因此该功能现在可能在更新的主线内核版本中可用。您可以通过加载 ecryptfs 模块并查看 sysfs 挂载点下 fs/ecryptfs/version_str 的内容来确定内核中可用的功能。

流行的 Linux 发行版带有 eCryptfs 用户空间软件包;请按照您的发行版的软件包安装程序安装 ecryptfs-utils 软件包。如果您的发行版尚未提供 eCryptfs 用户空间工具,您可以下载、构建和安装源代码 tarball。您可以从 eCryptfs SourceForge 站点 (ecryptfs.sourceforge.net) 获取用户空间组件。

如果 eCryptfs 构建为内核模块,则需要加载该模块

# modprobe ecryptfs

此时,您可以开始将 eCryptfs 与您当前使用的任何文件系统一起使用。要挂载 eCryptfs,请为加密文件指定底层目录,并为文件的解密视图指定 eCryptfs 挂载点

# mount -t ecryptfs /secret /secret

第一个路径是底层目录,第二个路径是 eCryptfs 挂载点。请注意,在本例中,底层目录和挂载点具有相同的路径。这些路径可以不同,但我建议执行覆盖挂载,以帮助确保只有 eCryptfs 能够访问底层文件系统中的文件。此命令将给定路径从底层目录转换为 eCryptfs 挂载点,持续到挂载结束。

执行挂载时,eCryptfs 挂载助手首先尝试从当前用户主目录中的 .ecryptfsrc 文件中读取选项,然后读取通过命令行提供的选项。挂载助手会交互式地提示输入 .ecryptfsrc 文件或命令行中未指定的任何强制选项。例如,可能会要求您选择密码短语和密码。

挂载成功完成后,写入 /secret 挂载点的文件将被透明地加密并写入底层文件系统中的 /secret 目录。底层 /secret 目录中存在的加密文件,并且可以使用挂载时指定的密钥解密的文件,在从 /secret eCryptfs 挂载点读取时,将以未加密的形式访问。

当您卸载 eCryptfs 并查看 /secret 时,您将看到加密的底层文件。您可能会首先注意到底层文件比在 eCryptfs 挂载点下查看的文件大。底层文件的确切大小取决于您的主机的页面大小以及写入的数据量。一般来说,最小的底层文件大小为 12KB 或您的主机页面大小加上 4KB,以较大者为准。这有助于确保 eCryptfs 文件和底层文件之间的页面对齐,从而提高性能。然后,当数据溢出到新的 4KB 数据区时,底层文件以 4KB 的增量增长。

每个底层文件的前面的额外空间包含有关该文件的加密元数据,例如属性标志和加密的文件加密密钥。将此信息放在文件内容中,可以方便地传输或备份文件,同时保留稍后访问文件所需的所有信息。但是,如果有很多小文件,标头可能会占用不成比例的大量空间。较新版本的 eCryptfs 可以将数据存储在扩展属性区域中,从而减小底层加密文件的大小;有关使用此功能的更多信息,请参阅 eCryptfs 在线文档,网址为 ecryptfs.sourceforge.net

如果您的内核具有公钥支持,则可以使用 eCryptfs 密钥模块之一来管理您的密钥。您可以通过查看 sysfs 挂载点下 fs/ecryptfs/version_str 的内容来检查您的内核版本的 eCryptfs 中是否提供支持。如果提供支持,您将看到 pubkey 列为受支持的功能之一。

可以通过挂载选项选择和参数化密钥模块。如果要使用 OpenSSL 密钥模块,首先需要生成一个公钥/私钥对以在 eCryptfs 中使用。要生成密钥对,请执行以下操作

  • 运行ecryptfs-manager.

  • 选择菜单选项 3。

  • 选择 openssl 密钥模块。

您还需要运行 eCryptfs 守护进程,以便管理内核-用户空间通信;只需运行可执行文件即可启动守护进程

# ecryptfsd

请注意,如果您仅使用密码短语操作模式,则无需运行守护进程。然后,假设您在 /usb-drive/mykey.pem 中创建了密钥,您将使用以下选项挂载

# mount -t ecryptfs \
  -o key=openssl:keyfile=/usb-drive/mykey.pem \
  /secret /secret

给定这些选项,eCryptfs 挂载助手会提示您输入密码短语,以保护密钥文件中包含的私钥。

您可以使用许多不同的密钥和密码组合(称为挂载上下文)挂载相同的底层目录,并且该特定上下文将应用于在挂载点下创建的任何新文件。对于当前版本的 eCryptfs,只有在使用相同上下文执行挂载时,才能访问在任何给定挂载上下文中创建的文件。

关于安全性的注意事项

与任何文件系统一样,在使用 eCryptfs 时,您应该定期备份您的数据。通过卸载 eCryptfs 并读取加密的底层文件,可以轻松安全地完成此操作。

eCryptfs 仅保护不受信任主机环境控制的静态数据的机密性。您应该正确使用访问控制机制,例如受信任主机上的 SELinux,以便规范对解密文件的访问。

默认情况下,eCryptfs 将保留访问底层文件本身的文件解密内容所需的所有信息。所需的只是最初用于创建文件的密钥。您应该采取措施保护此密钥。如果应用程序(例如增量备份实用程序)配置为仅读取加密的底层文件,则这些实用程序无需对文件应用任何进一步的加密,即可确保数据机密性。

如果您使用密码短语,请遵循选择和保护密码短语的常用最佳实践(例如,请参阅 www.iusmentis.com/security/passphrasefaq)。我建议尽可能使用公钥操作模式而不是密码短语模式。使用公钥模块时,请备份您的密钥文件并将其存储在物理安全的位置。如果您丢失了密钥,任何人都无法检索您的数据。请勿将未受保护的密码短语或公钥文件的副本与加密数据存储在同一介质上。

您可以自由选择通过 Linux 内核加密 API 提供的对称加密密码。eCryptfs 建议将 AES-128 作为默认密码。如果您的机器上提供硬件加速,并且内核加密 API 中选定的密码支持硬件加速,则 eCryptfs 加密和解密操作将自动进行硬件加速。

您应该采取措施确保敏感数据不会以未加密的形式写入辅助存储。配置写入敏感临时数据的应用程序时,应使其仅在 eCryptfs 挂载点下写入。您还应该使用 dm-crypt 以随机密钥加密交换空间。详细信息超出了本文的范围,但设置它的命令采用以下形式

# cryptsetup -c aes-cbc-plain -d /dev/random create \
  swap /dev/SWAPDEV
# mkswap /dev/mapper/swap
# swapon -p 1 /dev/mapper/swap

SWAPDEV 是您机器上的交换块设备(如果您不确定当前哪个设备用于交换,请参阅您的 /etc/fstab 文件)。您可以创建简单的启动脚本来自动设置加密的交换空间、运行 ecryptfsd 并执行 eCryptfs 挂载。有关编写启动脚本以及使用带有随机密钥的 dm-crypt 加密交换空间的更多详细信息,请查阅您的发行版的文档。

请注意,当前版本的 eCryptfs 仅加密文件内容。关于文件的元数据——例如,大小、名称、权限和扩展属性——对于任何有权访问加密底层文件的人来说都是可读的。未来在 eCryptfs 上的工作将包括加密或混淆其中一些元数据。

将块设备加密与 eCryptfs 结合使用可以结合两种机制提供的安全性,同时提供无缝访问各个加密底层文件的灵活性,尽管这会使加密和解密数据的处理开销大致增加一倍。如果只有辅助存储上的文件内容需要保密,则在大多数情况下,eCryptfs 本身就足够了。

未来工作

eCryptfs 旨在支持一系列高级密钥管理和策略功能。eCryptfs 的开发路线图包括每个文件多个密钥、根据创建文件的应用程序和文件写入位置为不同文件使用不同的密钥和密码、完整性强制以及与现有密钥基础设施和密钥管理设备更广泛的互操作性。这些功能将在未来的 Linux 内核版本中实现时可用。

结论

eCryptfs 是一种灵活的内核原生解决方案,可在辅助存储设备上以加密方式强制执行数据机密性。eCryptfs 可以以最小的努力部署在现有文件系统上。单个加密文件可以传输到运行 eCryptfs 的其他主机,并使用正确的密钥透明地访问。eCryptfs 密钥管理机制具有高度可扩展性。eCryptfs 适合用作强大而方便的数据机密性强制组件,以帮助保护在 Linux 环境中管理的数据。

FiST

石溪大学 (SUNY) 文件系统和存储实验室 (FSL) (filesystems.org) 开发了一个名为 FiST 的堆叠式文件系统框架。eCryptfs 派生自 Cryptfs,Cryptfs 是 FiST 中实现的示例文件系统之一。Unionfs 是 SUNY FSL 编写的另一个流行的堆叠式文件系统。

法律声明

这项工作代表作者的观点,不一定代表 IBM 的观点。

IBM 是国际商业机器公司在美国、其他国家或两者的注册商标。

Linux 是 Linus Torvalds 在美国、其他国家或两者的注册商标。

TrueCrypt 是 TrueCrypt 基金会的商标。

其他公司、产品和服务名称可能是其他公司的商标或服务标志。

Mike Halcrow (mhalcrow@us.ibm.com) 是 IBM Linux 技术中心的安全软件工程师,也是 eCryptfs 的首席架构师和开发人员。他还在奥斯汀的 UT 攻读计算机科学硕士学位。过去,他维护了 openCryptoki PKCS#11 应用程序,为 Linux 的通用准则 CAPP/EAL 安全认证工作做出了贡献,并编写了 BSD 安全级别 Linux 安全模块 (LSM),该模块在以前版本的 Linux 内核中发布。

加载 Disqus 评论