Seafile 服务端加密缺陷分析

概述

Seafile 是一个十分受欢迎的企业网盘，提供社区版供用户免费使用，也提供专业版供有更高需求的用户/企业使用。

当你使用 Seafile 创建了一个加密存储库的时候这个库内的文件在服务端也会被加密，防止服务器管理员获取文件内容。

不过这种加密存在缺陷，容易受到攻击。我翻了翻中文的搜索结果没有发现类似的文章，于是写下这篇文章提醒一下正在使用或者打算使用 Seafile 的用户。

本文章完成时 Seafile 的最新版本为 8.0.5。

攻击者可以通过猜测某个加密库内的某个文件的内容来获取该库内的其它文件的部分或全部明文。因为目前 Seafile 并不加密一些元数据比如目录名和文件名，所以根据文件名进行猜测是有可能的。比如 python 源代码文件的开头大概率是 import 关键字。

我们打开英文版的官方文档，看看 Seafile 的加密流程。

随机生成一个 32 Byte 的数字作为「文件密钥」。
通过用户为加密库指定的密码生成一个「派生密钥」和一个「初始化向量（IV）」，然后使用 AES-CBC 算法通过「派生密钥」和「初始化向量（IV）」加密「文件密钥」，得到被「被加密的文件密钥」。「被加密的文件密钥」会存储在服务端，解密时可以通过相同的方式计算出「派生密钥」和「初始化向量（IV）」用来解密「被加密的文件密钥」。
该加密库内的所有文件可以被「文件密钥」加密。

从上面过程中我们可以看出「派生密钥」和「初始化向量（IV）」从加密库创建时就被固定一下，并且不会变化，这实际上并不是正确的做法。因为按照 AES-CBC 的设计，不同的数据应该使用不同的且不可预测的「初始化向量（IV）」，否则就容易受到「已知明文攻击」。

已知明文攻击：攻击者利用已知明文和对应的密文进行攻击。

引入「初始化向量（IV）」是为了解决同一段明文总会被加密成同一段密文这一缺陷，因为这种加密方式难以抵御统计分析，攻击者可以通过密文中某一片段的出现的频率、位置和时间等猜测对应的明文。比如某段密文总是出现双方首次通信，则这段密文对应的明文很可能是「你好」之类的问候语。

引入「初始化向量（IV）」后就会让相同的明文产生不同的密文，但是如果「初始化向量（IV）」不变，同一段明文还是会产生相同的密文，所以算法设计时就要求「初始化向量（IV）」必须不可预测并且仅使用一次并且不可预测，简单来说就是使用随机的数据作为「初始化向量（IV）」。