一、摘要
将数据库存储在服务器上可以节省很多的维护成本，但是大多数的服务器都是不可信的，因此存储在其上的数据库需要进行加密。本文通过bilinear pairing实现了加密数据库的多用户上传和读取，适合数据库需要经常动态变化的情况。另外，该方案还实现了用户的新增和删除都对其他用户透明，减少了开销。
二、主要工作 （核心场景、框架或者算法）
该加密方案主要涉及两个对称密钥e和k，其中密钥e用于加密和解密数据库记录，密钥k用于加密和解密index。密钥e通过可信密钥服务器直接分发给用户，每个用户的e都相同；而密钥k则与关键字一一对应，即不同的用户，只要关键字相同，就会得到相同的加密密钥k，而密钥k的计算需要通过bilinear pairing和BLS Short Signature实现，如下图所示。
（一）首先是用户新增的过程，该过程中，由offline的线下服务器完成密钥的计算，生成密钥对（xu，ComKu），其中私钥xu以及用户加密数据库记录的对称密钥e发送给用户，ComKu发送给服务器存储，s是哈希列表的种子。
<center>
</center>
（二）用户上传数据的过程，主要为双线性映射的过程。首先用户通过哈希列表以及随机数rw计算g1=hs(w)^rw∈G1发送给服务器（rw保证了安全性），服务器根据公钥ComKu返回映射到G2空间的值，用户再根据私钥解密得到生成Index的对称密钥K，使用k加密Index=<r,[r]k>，使用e加密record，上传给服务器。
<center>
</center>
（三）用户查询及下载数据的过程。首先用户根据私钥xu生成查询，上传给服务器，服务器根据该用户的公钥ComKu以及哈希映射计算用于加密该关键字的对称密钥k'，并且对Index列表中的每一个条目<r,[r]k>进行匹配，若r=[[r]k]k',表示匹配成功，则该index对应的记录加入到返回给用户的队列中。
<center>
</center>
（四）用户的撤销过程。只需要可信密钥服务器通知server删除相应的公钥comku，则该用户就无法进行读写。
三、优点（动机、算法、写作）
- 实现了多用户的上传和下载，适用于数据库经常需要修改的情况
- 支持多关键字（作者提了一句说实现方法很简单，但并没有说明细节）
- 用户的新增和删除并不影响其他用户
四、缺点 （算法缺陷、写作逻辑漏洞、攻击场景漏洞、工作完成度）
- 搜索效率为O(m)，m为record的数目，不适合大型的数据库。
- 优化方案中提到了性能的优化，但仅限于特定的可以进行binary search的数据库
- 可信密钥服务器只维护了一个主密钥Kum以及对称密钥e，整个数据库只分为可访问与不可访问两类用户。在该场景中是合理的，但在我们的场景中，每一个用户的文件都相当于一个小型数据库，每一个用户甚至每一个文件都需要区分可访问与不可访问。
- 没有区分搜索权限和下载权限
五、可改进点（改进方法、启发）
- order preserving？（由下一篇论文得到启发 ）
六、对比
| CCS06 | MuPQ | ||
|---|---|---|---|
| 功能性分析 | 多关键字 | 不支持 | 支持 |
| 用户组细分 | 不支持 | 整个database只分为可访问与不可访问两类用户 | |
| 多用户上传 | 不支持 | 支持 | |
| 多用户下载 | 支持 | 支持 | |
| 搜索/下载权限区分 | 不区分 | 不区分 | |
| 效率分析 | 用户的新增和删除是否对其他用户透明 | 透明 | 不透明 |
| 搜索效率 | O(1) | O(M) | |
| 服务器开销 | |||
| 安全性分析 | search pattern | adaptive方案可以隐藏 | 可以隐藏 |
| access pattern | 不支持 | 不支持 | |
| 结果验证 | 不支持 | 不支持 | |
| 方案基础 | BE-based | Bilinear pairing |
