个人工具
登录
查看“Ecryptfs企业级加密文件系统”的源代码 - Ubuntu中文
页面
讨论
查看源代码
历史
搜索
导航
首页
最近更改
随机页面
页面分类
帮助
编辑
编辑指南
沙盒
新闻动态
字词处理
工具
链入页面
相关更改
特殊页面
页面信息
查看“Ecryptfs企业级加密文件系统”的源代码
来自Ubuntu中文
←
Ecryptfs企业级加密文件系统
跳转至:
导航
,
搜索
因为以下原因,你没有权限编辑本页:
您所请求的操作仅限于该用户组的用户使用:
用户
您可以查看与复制此页面的源代码。
== 延伸阅读 == 引用自:http://www.ibm.com/developerworks/cn/linux/l-cn-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 加密文件系统的架构 http://www.ibm.com/developerworks/cn/linux/l-cn-ecryptfs/image002.jpg eCryptfs Layer 是一个比较完备的内核文件系统模块,但是没有实现在物理介质上存取数据的功能。在 eCryptfs Layer自己的数据结构中,加入了指向下层文件系统数据结构的指针,通过这些指针,eCryptfs就可以存取加密文件。清单 2 列出几种主要的数据结构: 清单 2. eCryptfs Layer 主要数据结构 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 加密/解密操作流程图 http://www.ibm.com/developerworks/cn/linux/l-cn-ecryptfs/image003.jpg === 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 等重要信息。
返回至
Ecryptfs企业级加密文件系统
。