Linux系统中的FBE实现方案和特点

Linux系统FBE

从Linux系统软件架构看，典型FDE和FBE实现方案分布如下图，包括基于dm-crypt的软件FDE方案、基于通用文件系统的fscrypt FBE方案、基于VFS的eCryptfs FBE方案，以及众多基于FUSE的FBE方案。

前面章节已经简单介绍过基于dm-crypt的FDE方案在ubuntu虚拟机上的验证情况，这里先简单介绍Linux系统和内核的几种软件FBE实现方案和特点，后续章节会以eCryptfs为例做详细分析。

FUSE-Based

FUSE即Filesystem in Userspace，用户态文件系统。FUSE设计初衷就是为方便用户不修改编译内核的情况下，在user space实现定制文件系统。FUSE架构原理和实现如下图，内核态FUSE和用户态libfuse为App –》 VFS -》 用户文件系统链路服务，用户定制实现主要在User-Level Filesystem部分。

由于天然的灵活性，基于FUSE实现FBE的方案有很多，例如gocryptfs、EncFS、CryFS、securefs等。但是，FUSE引入的多次系统调用和拷贝等开销，也导致基于FUSE的FBE方案通常性能都不好。gocryptfs项目有一个stackable FBE各方案的对比分析，该分析数据也验证说明了FUSE FBE方案的优缺点。

首先是各种stackable FBE方案介绍和整体特点，从数量上看，FUSE FBE方案占据绝大多数，非FUSE方案只有eCryptfs。

其次，相比于eCryptfs，FUSE方案在性能上整体处于劣势。尽管gocryptfs在顺序读写上性能不错，但在其他测试如解压缩、MD5计算、目录递归访问/删除等测试项上看，劣势也比较明显。这和我们在3.2章节对比FDE和FBE、以及分析磁盘加密在软件栈不同层级实现的效果差异是一致的。

eCryptfs

eCryptfs衍生于Cryptfs项目，早期方案和设计思想源自2005和2007的两篇论文，即《eCryptfs： an enterprise-class cryptographic filesystem for Linux》和《eCryptfs： a Stacked Cryptographic Filesystem》。eCryptfs项目分为内核部分和用户态部分，内核态代码于v2.6.19版本合入社区主线，用户态代码在软件包ecryptfs-utils中维护。

eCryptfs和上面介绍的FUSE方案一样，也属于stackable FBE类型，故不依赖于OS底层文件系统类型，可以堆叠在各种文件系统之上，灵活性很好。也支持对不同文件、目录加密，以及文件名加密。

当前eCryptfs项目开源社区活跃度不高，早期用户/产品也在迁移，但其方案和设计原理仍然值得深入学习分析。

fscrypt

fscrypt是在内核文件系统上实现的一个native FBE方案。fscrypt特性也包括内核态和用户态两部分，内核态部分是实现在fs/crypto目录的公用加解密模块，支持ext4、F2FS、UBIFS文件系统集成使用。用户态工具fscrypt则实现各种命令行工具方便用户使用。

fscrypt作为FBE方案，支持不同目录/文件采用不同密钥，对于metadata，fscrypt支持文件名filename加密，其他metadata如timestamp、size、attribute等不加密。fscrypt最大的应用即Android
采用的FBE方案，结合F2FS文件系统，对手机上的数据进行data at rest encryption保护。本文受限于篇幅，不做详细分析。