Shell's Home

Dec 17, 2017 - 1 minute read - Comments

在云存储上叠加加密文件系统

目标很简单。云存储上很多文件都挺私人的,直接放着很吓人。虽说云存储采用各种方法来保证你的安全,但是世界上没有绝对的安全。万一密码泄漏,或者更糟糕,云存储泄漏。此时你的各种文件就在网络上裸奔了。

最简单的解决方法是什么?在底层存储上套一层加密呗。不过由于是云存储,所以基于块设备的加密方案不能用,例如LUKS。否则你同步到云上的就是一个超级巨大的块文件,然后每次修改,云存储客户端都要找到差别上传。这太蛋疼了。正解是每个文件分别加密上传。但即便如此,对于超大文件进行加密后依然会影响上传效率,请提前考虑一下这个问题。

同时又要注意,云存储用的加密文件系统和普通的加密文件系统还有点差别。很多加密文件系统的daemon会认为自己是唯一一个会访问加密内容的进程,而云存储可能随时接收来自远程的修改。所以这会造成一些问题。

备选方案

我对比了四种方案,EncFS,CryFS,GoCryptFS,eCryptFS。对比的方法是用这四种分别建立一个加密目录,然后用不同的方法做写入测试,看他的各种参数。顺便说一句,如果你要看的话,其实看这份表格就好。我只是在自己的机器上复现了一下,顺便了解一下各家特点。

测试语句:

time dd if=/dev/zero of=test bs=1048576 count=1024
time dd if=/dev/zero of=test bs=1024 count=1048576
time tar xf linux-4.13.12.tar.xz

其中,在裸盘上直接解压内核源码耗时7.568s,空间使用870M。

数据对比

+---------+-------+-----+-------+-----+-------+-----+--------------+
|         |time1  |size1|time2  |size2|time3  |size3|comment       |
+---------+-------+-----+-------+-----+-------+-----+--------------+
|EncFS    |13.210s|1.1G |39.039s|1.1G |26.496s|894M |              |
+---------+-------+-----+-------+-----+-------+-----+--------------+
|CryFS    |9.327s |1.1G |21.230s|1.1G |42.918s|2.5G |删除耗时2.804s|
+---------+-------+-----+-------+-----+-------+-----+--------------+
|GoCryptFS|3.515s |1.1G |28.180s|1.1G |19.874s|918M |              |
+---------+-------+-----+-------+-----+-------+-----+--------------+
|eCryptFS |3.132s |1.1G |10.218s|1.1G |9.448s |1.4G |              |
+---------+-------+-----+-------+-----+-------+-----+--------------+

解读

首先说怎么解读。time1是连续写入性能,time2是离散写入性能,time3是小文件写入性能,size3是大量小文件膨胀系统。size1和size2没啥用。

下面先看性能。从性能上看,最优秀的是eCryptFS。这是理所当然,因为这是唯一一个内核态而且和内核整合的系统。GoCryptFS次之。EncFS要慢上好多。至于CryFS,一开始写小文件就原型毕露了。何况这是唯一一个删除大文件时间超过1s的,达到2.8s。你看我其他系统测试里都没写。

然后是膨胀率。EncFS膨胀2.75%,CryFS膨胀近三倍,GoCryptFS膨胀5.52%,eCryptFS膨胀65%。相比起来,EncFS膨胀率最小,GoCryptFS次之,CryFS最糟糕。

安全性

下面是同一个人出的三份审计报告:

根据报告可以得到这么几个意见。

  • EncFS有安全性隐患,目前未解决。主要隐患来自于文件块加密模式上。如果攻击者有机会获得多份密文副本,那么就是不安全的。
  • GoCryptFS有一定安全问题,目前未解决。下面细说。
  • eCryptFS需要进一步审计,目前可视为安全。

综叙

可能出乎大家意料,我首先排除了encfs和ecryptfs。encfs是因为有安全性隐患。ecryptfs是因为不便于使用和不兼容云存储模式。ecryptfs在每次挂载时都需要独立输入所有参数,这样使用起来比较不方便。更糟糕的是,ecryptfs并不支持同时有人访问加密数据本身。这样会造成竞争问题。对于一个内核级的东西来说,这有极大的危险性。同时,这货的膨胀率有点高。

然后在CryFS和GoCryptFS里,我选择GoCryptFS。虽然CryFS是唯一一个明确声明自己兼容云存储的,但是其膨胀率实在太高了。虽然是云存储,但是毕竟要考虑性价比的。

那么GoCryptFS的安全问题是什么呢?主要隐患来自和云存储混用时,攻击者虽然对文件内容一无所知,但是可以修改文件内容。例如将其他加密文件复制过来,或者将部分内容嫁接过来。审计报告里提供了一系列的POC来说明这一风险。这一风险对于特定情况的用户来说是非常危险的,例如在加密区域存储多个可信身份/帐号身份文件的人。

很幸运,我对这方面没要求。GoCryptFS的膨胀率不大,仅高于EncFS,完全可以接受。性能也不错,仅次于eCryptFS。使用非常方便,同时还能提供过得去的安全特性。因此综合上面所有情况,我选择GoCryptFS作为云存储上叠加的加密文件系统。

京都游记 similan船宿

comments powered by Disqus