Ecryptfs企业级加密文件系统

联系我：一般还是使用站内短信通知比较快。 http://forum.ubuntu.org.cn/ucp.phppm&mode=compose&u=171468

安装系统时提示是否加密主文件夹，使用的就是这个加密系统：）

保护敏感数据不被泄漏成为人们关注的热点问题。入侵者除了直接盗取物理存储设备，还可以通过 络攻击来窃夺文件数据；而且，由于共享的需求，敏感数据会由多人访问，这也增大了泄漏的可能性。对数据或文件进行加密已经成为一种公认的比较成功的保护方法。事实上，人们早已开发了许多优秀的加密算法，如 DES、AES、RSA 等，并且有一些应用程序如 crypt 使用这些加密算法，用户通过这些工具手工地完成加密、解密的工作。由于这些应用程序操作麻烦、没有和整个系统紧密地结合而且容易受到攻击，因此一般用户并不愿意使用。

加密文件系统（比如eCryptfs）通过将加密服务集成到文件系统这一层面来解决上面的问题。加密文件的内容一般经过对称密钥算法加密后以密文的形式存放在物理介质上，即使文件丢失或被窃取，在加密密钥未泄漏的情况下，非授权用户几乎无法通过密文逆向获得文件的明文，从而保证了高安全性。与此同时，授权用户对加密文件的访问则非常方便。用户通过初始身份认证后，对加密文件的访问和普通文件没有什么区别，就好像该文件并没有被加密过，这是因为加密文件系统自动地在后台做了相关的加密和解密的工作。由于加密文件系统一般工作在内核态，普通的攻击比较难于奏效。还有一类系统级加密方案是基于块设备，与它们相比，加密文件系统具有更多的优势，例如：

• 支持文件粒度的加密，也就是说，用户可以选择对哪些文件或目录加密。而且，应用程序不用关心文件是否被加密，可以完全透明地访问加密文件。
• 无需预先保留足够的空间，用户可以随时加密或恢复文件。
• 对单个加密文件更改密钥和加密算法比较容易。
• 不同的文件可以使用不同的加密算法和密钥，增大了破解的难度。
• 只有加密文件才需要特殊的加密/解密处理，普通文件的存取没有额外开销。
• 加密文件转移到别的物理介质上时，没有额外的加密/解密开销。
• 附加一点，ecryptfs 的解密层存在于内存(内存不足时可能使用 到交换分区)。硬盘上面保存的只有加密数据。这样即使硬盘被偷了，使用数据还原软件也不可能得到 解密文件。不是像普通的加密软件、压缩软件把 解密文件缓存于硬盘上。你即使删除了，使用数据还原软件依然有可能得到 解密文件。

然后就可以开始使用了。因为很简单使用命令界面就能解决问题，所以没有图形界面。但是不用担心，我会把每一步讲解清楚。没有图形界面还有一个好处：隐蔽性高

这里举个单独加密文件夹的例子，而不是按 上流行的方式：把主文件夹加密。我认为这种操作简单、独立涉及的东西少,效率高。

＊1，新建一个测试文件夹：ecryptfs_test使用这个文件夹存放加密文件命令：

mount 是挂载命令。-t 是指定文件类型。ecryptfs 就是我们使用的加密文件类型。！这里换一个命令举例说明一下

real_path 是真实存放数据的地方；ecryptfs_mounted_path 是指你要把文件夹挂载于哪里（具体位置可以随意）

推荐：ecryptfs_mounted_path 和 真实目录 real_path 不一致，这样非授权用户不能通过原路径访问加密文件。

＊2，mount 需要root权限，我们使用 命令sudo ，来以root身份运行命令结果如下：

eCryptfs Layer 是一个比较完备的内核文件系统模块，但是没有实现在物理介质上存取数据的功能。在 eCryptfs Layer自己的数据结构中，加入了指向下层文件系统数据结构的指针，通过这些指针，eCryptfs就可以存取加密文件。清单 2 列出几种主要的数据结构：

清单 2. eCryptfs Layer 主要数据结构

Keystore 和用户态的 eCryptfs Daemon 进程一起负责密钥管理的工作。eCryptfs Layer 首次打开一个文件时，通过下层文件系统读取该文件的头部元数据，交与 Keystore 模块进行 EFEK（加密后的 FEK）的解密。前面已经提及，因为允许多人共享加密文件，头部元数据中可以有一串 EFEK。EFEK 和相应的公钥算法/口令的描述构成一个鉴别标识符，由 ecryptfs_auth_tok 结构表示。Keystore 依次解析加密文件的每一个 ecryptfs_auth_tok 结构：首先在所有进程的密钥链（key ring）中查看是否有相对应的私钥/口令，如果没有找到，Keystore 则发一个消息给 eCryptfs Daemon，由它提示用户输入口令或导入私钥。第一个被解析成功的 ecryptfs_auth_tok 结构用于解密 FEK。如果 EFEK 是用公钥加密算法加密的，因为目前 Kernel Crypto API 并不支持公钥加密算法，Keystore 必须把 ecryptfs_auth_tok 结构发给 eCryptfs Daemon，由它调用 Key Module API 来使用 TPM 或 OpenSSL库解密 FEK。解密后的 FEK 以及加密文件内容所用的对称密钥算法的描述信息存放在 ecryptfs_inode_info 结构的 crypt_stat 成员中。eCryptfs Layer 创建一个新文件时，Keystore 利用内核提供的随机函数创建一个 FEK；新文件关闭时，Keystore 和 eCryptfs Daemon 合作为每个授权用户创建相应 EFEK，一齐存放在加密文件的头部元数据中。

eCryptfs 采用 OpenPGP 的文件格式存放加密文件，详情参阅 RFC 2440 规范[4]。我们知道，对称密钥加密算法以块为单位进行加密/解密，例如 AES 算法中的块大小为 128 位。因此 eCryptfs 将加密文件分成多个逻辑块，称为 extent。当读入一个 extent 中的任何部分的密文时，整个 extent 被读入 Page Cache，通过 Kernel Crypto API 被解密；当 extent 中的任何部分的明文数据被写回磁盘时，需要加密并写回整个 extent（参见图 5[5]）。extent 的大小是可调的，但是不会大于物理页的尺寸。当前的版本中的 extent 默认值等于物理页大小，因此在 IA32 体系结构下就是 4096 字节。加密文件的头部存放元数据，包括元数据长度、标志位以及 EFEK 链，目前元数据的最小长度为 8192 字节。

图 3. eCryptfs 加密/解密操作流程图

写操作性能比较差。笔者用 iozone 测试了 eCryptfs 的性能，发现读操作的开销不算太大，最多降低 29%，有些小文件测试项目反而性能更好；对于写操作，所有测试项目的结果都很差，普遍下降 16 倍左右。这是因为 Page Cache 里面只存放明文，因此首次数据的读取需要解密操作，后续的读操作没有开销；而每一次写 x 字节的数据，就会涉及 ((x – 1) / extent_size + 1) * extent_size 字节的加密操作，因此开销比较大。

有两种情况可能造成信息泄漏：a. 当系统内存不足时，Page Cache 中的加密文件的明文页可能会被交换到 swap 区，目前的解决方法是用 dm-crypt 加密 swap 区。b. 应用程序也有可能在读取加密文件后，将其中某些内容以临时文件的方式写入未挂载 eCryptfs 的目录中（比如直接写到 /tmp 中），解决方案是配置应用程序或修改其实现。eCryptfs 实现的安全性完全依赖于操作系统自身的安全。如果 Linux Kernel 被攻陷，那么黑客可以轻而易举地获得文件的明文，FEK 等重要信息。

联系我：一般还是使用站内短信通知比较快。 http://forum.ubuntu.org.cn/ucp.phppm&mode=compose&u=171468

HI,cat650:

我看了你关于ecryptfs使用详解一文，对于文件加密粒度方面有所疑问。

答：

在linux下 mount 命令只能挂载于目录上。但不影响单个文件的加密工作。

在例子中你应该看到，假设有一个文件夹text被加密（使用加密方法a，加密长度a，密码a；挂载于新建文件夹text－a 下），我们放入ta、tb文件。

我们对text文件夹进行再次加密挂载（使用加密方法b，加密长度b，密码b；挂载于新建文件夹text－b下），仅操作其中一个文件（新建文件tx，并存入新记录）。

此时我们再看text文件夹，ta、tb使用的是加密方法a，加密长度a，密码a；tx使用加密方法b，加密长度b，密码b。也就是说——选择对哪些文件或目录（目录操作类似）加密。做到文件粒度支持。

如果要更改tb文件的加密方式也很简单（上述条件不变的情况下）：新建加密挂载（使用加密方法c，加密长度c，密码c；挂载于新建文件夹text－c下）。把text－a下的tb文件移动到text-c下。密码更改完成。——对单个加密文件更改密钥和加密算法比较容易。

此时ta、tb、tc使用的是完全不同的 加密方法，加密长度，密码——不同的文件可以使用不同的加密算法和密钥，增大了破解的难度。

问题明白了吗特性是因为这个加密层是存在于内存上（或虚拟内存内）。

文章知识点与官方知识档案匹配，可进一步学习相关知识算法技能树首页概览34716 人正在系统学习中