使用 eCryptfseCryptfs 简介eCryptfs 是在 Linux 内核 2.6.19 版本中引入的一个功能强大的企业级加密文件系统，堆叠在其它文件系统之上（如 Ext2, Ext3, ReiserFS, JFS 等），为应用程序提供透明、动态、高效和安全的加密功能。
本质上，eCryptfs 就像是一个内核版本的 Pretty Good Privacy（PGP）[3] 服务，插在 VFS（虚拟文件系统层）和 下层物理文件系统之间，充当一个“过滤器”的角色。用户应用程序对加密文件的写请求，经系统调用层到达 VFS 层，VFS 转给 eCryptfs 文件系统组件（后面会介绍）处理，处理完毕后，再转给下层物理文件系统；读请求（包括打开文件）流程则相反。
eCryptfs 的设计受到OpenPGP 规范的影响，使用了两种方法来加密单个文件：
- eCryptfs 先使用一种对称密钥加密算法来加密文件的内容，推荐使用 AES-128 算法，密钥 FEK（File Encryption Key）随机产生。有些加密文件系统为多个加密文件或整个系统使用同一个 FEK（甚至不是随机产生的），这会损害系统安全性，因为：a. 如果 FEK 泄漏，多个或所有的加密文件将被轻松解密；b. 如果部分明文泄漏，攻击者可能推测出其它加密文件的内容；c. 攻击者可能从丰富的密文中推测 FEK。
- 显然 FEK 不能以明文的形式存放，因此 eCryptfs 使用用户提供的口令（Passphrase）、公开密钥算法（如 RSA 算法）或 TPM（Trusted Platform Module）的公钥来加密保护刚才提及的 FEK。如果使用用户口令，则口令先被散列函数处理，然后再使用一种对称密钥算法加密 FEK。口令/公钥称为 FEFEK（File Encryption Key Encryption Key），加密后的 FEK 则称为 EFEK（Encrypted File Encryption Key）。由于允许多个授权用户访问同一个加密文件，因此 EFEK 可能有多份。
这种综合的方式既保证了加密解密文件数据的速度，又极大地提高了安全性。虽然文件名没有数据那么重要，但是入侵者可以通过文件名获得有用的信息或者确定攻击目标，因此，最新版的 eCryptfs 支持文件名的加密。
eCryptfs 使用方法eCryptfs 需要相应的内核模块和用户态的工具同时配合使用。用户态的工具可以从 获得，使用 Debian 或 Ubuntu 系统的用户，用 apt-get 命令安装 ecryptfs-utils 包即可。如果用户自行编译内核，则需要如下选项：
清单 1. 使用 eCryptfs 所需的内核选项1
2
3
4
5
6
7
8
9
10
| General setup --->
Prompt for development and/or incomplete code/drivers
File systems --->
Miscellaneous filesystems --->
<M> eCrypt filesystem layer support (EXPERIMENTAL)
Security options --->
<M> Enable access key retention support
Cryptographic API --->
<M> MD5 digest algorithm
<M> AES cipher algorithms
|
首先需要加载 eCryptfs 内核模块，执行modprobe ecryptfs。然后将 eCryptfs 挂载到准备存放加密文件的目录，执行 sudo mount -t ecryptfs real_pathecryptfs_mounted_path。推荐ecryptfs_mounted_path 和 真实目录 real_path 一致，这样非授权用户不能通过原路径访问加密文件。
图 1. eCryptfs 挂载结果 eCryptfs默认使用 AES-128 算法以及用口令加密 FEK，更多挂载选项请参考 eCryptfs 的 man page。如果用户想使用公钥加密算法加密 FEK，需要事先用 OpenSSL 产生公钥/私钥对。用户还可以在主目录下的 .ecryptfsrc 文件中写入缺省选项，配置文件的格式请参阅 。
eCryptfs 的设计eCryptfs 设计目标为了评估一个加密解决方案的可行性，企业往往要考虑诸多因素，例如员工的学习曲线、增量备份是否受到影响、密钥丢失的话如何防止信息泄漏或如何恢复信息、转换及使用成本、潜在的风险等等。eCryptfs 在设计之初，充分考虑企业用户的如下需求：
- 易于部署。eCryptfs 完全不需要对 Linux Kernel 的其它组件做任何修改，可以作为一个独立的内核模块进行部署。同时，eCryptfs 也不需要额外的前期准备和转换过程。
- 用户能够自由选择下层文件系统来存放加密文件。由于不修改 VFS 层，eCryptfs 通过挂载（mount）到一个已存在的目录之上的方式实现堆叠的功能。对 eCryptfs 挂载点中文件的访问首先被重定向到 eCryptfs 内核文件系统模块中。
- 易于使用。每次使用 eCryptfs 前，用户只需执行 mount 命令，随后 eCryptfs自动完成相关的密钥产生/读取、文件的动态加密/解密和元数据保存等工作。
- 充分利用已有的成熟安全技术。例如，eCryptfs 对于加密文件采用 OpenPGP 的文件格式、通过 Kernel Crypto API使用内核实现的对称密钥加密算法和散列算法等。
- 增强安全性。eCryptfs 的安全性最终完全依赖于解密 FEK 时所需的口令或私钥。通过利用 TPM 硬件（TPM可以产生公钥/私钥对，硬件直接执行加密/解密操作，而且私钥无法从硬件芯片中获得），eCryptfs 最大程度上保证私钥不被泄漏。
- 支持增量备份。eCryptfs 将元数据和密文保存在同一个文件中，从而完美的支持增量备份及文件迁移。
- 密钥托管。用户可以预先指定恢复帐号，万一遗失加密 FEK 的口令/私钥，也可以通过恢复帐号重新获得文件的明文；但是如果未指定恢复帐号，即使系统管理员也无法恢复文件内容。
- 丰富的配置策略。当应用程序在 eCryptfs 的挂载点目录中创建新文件的时候，eCryptfs 必须做出许多决定，比如新文件是否加密、使用何种算法、FEK 长度、是否使用 TPM 等等。eCryptfs 支持与 Apache 类似的策略文件，用户可以根据具体的应用程序、目录进行详细的配置。
eCryptfs 的架构图 2. eCryptfs 加密文件系统的架构 eCryptfs Layer 是一个比较完备的内核文件系统模块，但是没有实现在物理介质上存取数据的功能。在 eCryptfs Layer自己的数据结构中，加入了指向下层文件系统数据结构的指针，通过这些指针，eCryptfs就可以存取加密文件。清单 2 列出几种主要的数据结构：
清单 2. eCryptfs Layer 主要数据结构1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
| static struct file_system_type ecryptfs_fs_type = {
.owner = THIS_MODULE,
.name = "ecryptfs",
.get_sb = ecryptfs_get_sb,
.kill_sb = ecryptfs_kill_block_super,
.fs_flags = 0
};
struct ecryptfs_sb_info {
struct super_block *wsi_sb;
struct ecryptfs_mount_crypt_stat mount_crypt_stat;
};
struct ecryptfs_inode_info {
struct inode vfs_inode;
struct inode *wii_inode;
struct file *lower_file; /* wii_inode, lower_file 指向下层文件系统对应的数据结构 */
struct mutex lower_file_mutex;
struct ecryptfs_crypt_stat crypt_stat;
};
struct ecryptfs_dentry_info {
struct path lower_path; /* 下层文件系统的 dentry */
struct ecryptfs_crypt_stat *crypt_stat;
};
struct ecryptfs_file_info {
struct file *wfi_file;
struct ecryptfs_crypt_stat *crypt_stat;
};
|
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 加密/解密操作流程图 eCryptfs 的不足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 等重要信息。
|
