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 forLinux》和《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保护。本文受限于篇幅,不做详细分析。
- Linux
+关注
关注
87文章
11102浏览量
207653 - 磁盘
+关注
关注
1文章
355浏览量
25064 - 虚拟机
+关注
关注
1文章
881浏览量
27748
发布评论请先登录
相关推荐
评论