ecryptfs文件系统中的信息泄漏

#1 楼

（公开：我是您所询问的功能的作者（一个很好的问题！）。）

Ubuntu的“加密主目录”功能使用eCryptfs作为文件系统加密技术。 eCryptfs是直接内置在Linux内核中的分层文件系统。它将一个目录安装在另一个目录之上。顶层目录实际上只是一个“虚拟”挂载点。应用程序（和人员）可以在该目录中操作并读取和写入数据，而无需了解或不了解其下发生的加密。较低的目录是实际的加密文件存储在磁盘上的位置。

此方法具有多个优点。与dmcrypt或全盘加密不同，您不必预先分配固定数量的专用于加密的空间。您还可以将加密的内容更多地限制在您真正独特的信息上（提高整体系统性能和功耗）。用户之间存在一些特权分离，每个用户都有自己的唯一安装点和加密密钥。并且此特定功能已挂接到PAM中，因此登录时会自动挂载目录，而注销时会挂载目录。同样，每个文件都使用唯一的随机生成的密钥加密，称为“ fek”（存储在文件的标头中，并用MOUNT密码包装）。这意味着两个等同于二进制的明文文件将加密为两个完全不同的密文！

另一方面，您应该注意一些事情-现在要注意您的问题！


上下文件结构几乎相同，并且可能会推断出一些文件名（基于默认的Ubuntu主目录框架）
文件权限，文件所有权和文件时间戳未加密（因此具有奇怪权限（例如0123）的文件可能会突出）
加密的文件名将明文文件名的上限限制为约160个字符（因为文件名加密需要填充）
如果使用的是Ubuntu Encrypted Home，则交换必须绝对加密，因为任何位置的内存都可以交换到磁盘上时间（当然，如果您使系统处于休眠状态）
当文件系统被主动挂载时，只有Unix运行时自由访问控制可以保护您免受系统上其他用户的访问（请注意，主目录的权限为0700）
主动挂载文件系统后，eCryptfs不会保护您免受root用户的侵害。
除非将~/.ecryptfs/wrapped-passphrase从本地系统上移到可移动介质（如USB记忆棒或闪存盘）上，否则登录密码是加密的弱点

现在，尽管如此，我仍然相信Ubuntu的Encrypted Home在安全性和可用性之间实现了出色的平衡。设置非常简单，并具有良好的登录密码，它为$HOME中的所有数据提供了非常强大的保护，使其免受离线攻击。换句话说，如果有人亲自偷走了您的笔记本电脑，启动了实时CD并开始挖掘您的$HOME/.Private加密数据，他们可能会搜集有关文件名，目录结构和时间戳的一些信息。但是要获取任何特定文件的内容，它们将需要以下之一：


您的LOGIN密码短语和您的打包密码文件
明文，长128位，随机MOUNT密码（存储在包装的密码文件中）
足够的时间来强制2中的128位密钥。
AES256中的缺陷

有关更多信息，我在eCryptfs上撰写了杂志文章和一系列博客文章。

#2 楼

eCryptfs信息泄漏可能会通过各种渠道发生。最严重和常见的泄漏点是交换。如前所述，Ubuntu现在对此进行了加密，但是我被告知启用该功能后，休眠状态将被破坏。其他发行版不一定会确保使用eCryptfs时对交换的加密进行加密。通过在VM中运行eCryptfs，保存状态并在内存映像中搜索关键资料，您可以看到问题的严重程度。将密钥存储在USB驱动器上不会对任何有权访问进程/内核内存的用户（例如root）有很大帮助。如果没有额外的内核强化和/或MAC，eCryptfs对于恶意的root用户是完全无效的。我也不会重提几乎每一个通用计算机的加密系统都容易受到的冷启动或DMA攻击。 tmp或/ var。试图将每个应用程序都固定下来很困难。

您当然可以使用概要分析和机器学习技术来推断有关正在写入的数据类型和正在写入数据的应用程序的信息。例如，我已经成功地应用了kNN模型，其功能仅是在一段时间内读写eCryptfs的次数。如果/当eCryptfs在NFS / SMB上运行时，将是泄漏。其他更容易观察到的功能，例如近似文件大小，近似文件名长度和目录结构，可以揭示您要存储的数据类型。例如，我可以轻松地确定您的包装盒上是否有Tor或TrueCrypt的源代码，因为该文件/目录结构的数量熵很低。

Ninefingers提到的演示文稿中的CBC攻击不适用于eCryptfs或BitLocker，它们都具有4096字节的CBC范围和不可预测的IV。我查看了XTS规范，但没有看到它比带AES-CBC和Elephant扩散器的BitLocker更加安全。

尽管eCryptfs有弱点，但总比没有好，并且eCryptfs部署的简便性使人们更有可能加密而不是不加密。就是说，如果您想获得最佳保护，以确保机盒中物理驱动器上的静态数据机密性，我建议使用Win7 + BitLocker + TPM部署FVE，而不是使用Linux进行按文件加密+ eCryptfs。

（编辑：有人告诉我，我应该在这样的帖子上说明一下。我设计/实现了eCryptfs的加密货币，我是Microsoft BitLocker团队的一名高级开发人员，年。）

#3 楼

因此，我在安全性SE上回答了这个问题，然后很快意识到我完全误解了问题并解释了您已经知道的所有内容。

我脑海中的问题可以概括为：-是否对每个加密数据-文件基础而不是整个磁盘基础增加了整个密码安全性的任何风险（暂时忽略了如果应用程序写入/tmp的事实……我们知道，并且该问题对于所有部分加密的系统都是正确的）。

我要说不-实际上相反。 CBC下的整个磁盘加密可能是一个问题。我提出这一主张的依据是，尽管您可以从文件的大小中推断出有关文件的信息，从而粗略猜测内容，包括分隔符（如幻数，已知模式，填充等），但CBC模式的设计目的是消除重复的内容。关键时刻表问题。具体来说，以AES为例，您的密钥会进行密钥扩展以形成密钥时间表，这是在密码中使用的较长数据。如果您选择的数据长度与此计划相同，并重复X次然后再将其加密，则应该看到X份相同的密文。此属性使ECB随数据集的增长而出现问题。

CBC模式在相同程度上没有问题-加密之前，前一个密文与下一个明文块进行了异或运算，表示明文不再与关键计划表重复。

但是确实存在一些问题。此演示文稿全部涉及磁盘加密挑战，并介绍了应用于完整磁盘时CBC的几个问题。值得注意的是生日悖论结论-根据信鸽原理，在达到一定大小（$ 2 ^ {b / 2} $，其中$ b $是块的大小）之后，您用尽了唯一的组合，字节开始重复，从而泄漏信息。因此，取决于配置，存在CBC可行的上限。

因此，使用CBC对每个文件进行加密（文件本身未达到这些值）可能更安全。现代全盘加密技术着眼于其他方法，例如XTS，旨在解决此类问题以及使用CBC解决并行加密问题（即，您无法做到）。