读书笔记--Lightweight Privacy-Preserving Spatial Keyword Query over Encrypted Cloud Data

论文出处：2022 IEEE 42nd International Conference on Distributed Computing Systems CCF B类会议

研究背景：

1）ASPE方案可以实现有效的可搜索加密，但是已被证实不安全，不能抵抗已知明文攻击，所以要改进ASPE技术
2）普通的空间关键字文本数据加密会生成大量密文，陷门也同样，会导致存储和计算成本上升，所以要引入轻量级查询技术

主要贡献：

1）使用Geohash算法来实现近似的空间范围查询，只需要用户提供空间坐标和近似的范围值。然后，针对空间范围和多关键字设计统一索引，实现空间关键字查询。
2）通过添加一些随机数和随机排列，使ASPE在选择明文攻击(IND-CPA)下不可区分，增强了ASPE的安全性
3）将增强的ASPE和geohash结合，降低密文量，提高查询效率

预备知识：

geohash算法：

是一种地理编码方法，将地理空间递归划分为小网格，将每个网格的二维坐标转换为Geohash码，每个Geohash码代表一个特定的矩形区域，geohash码长度越长那么对应的矩形就越小，范围也更精确，图中（8,13）对应s33jxb6,geohash码还可以按照base32的规则转化为十进制向量，s33jxb6（geohash）—>（24, 3, 3, 17, 29, 10, 6, 7）；
用geohash码对空间范围做划分，通过比较两个位置对应的geohash码的相同前缀长度来确定两个位置的最远距离

增强ASPE技术：

通过判断密文和陷门的标量积是否等0来判断距离或者相似度是否在阈值内 ；
对密文和令牌使用划分向量进行划分（实现隐私保护），一个0加1等，另一个0等1加，以保证最后在密文上计算的结果和在明文上计算的结果等价；
数据加密0等1加：

陷门生成0加1等：

系统模型：

此系统含三种实体：数据拥有者、查询用户、云服务器
数据拥有者：为每个数据对象生成索引，并对数据和索引加密后外包给云；向查询用户分发加密密钥；
查询用户：根据查询请求（查询坐标，查询关键字，查询范围半径）生成查询陷门发送给云并获得查询结果
云服务器：在密文上执行搜索并返回满足条件对象的标识符

方案使用技术：

增强ASPE（EASPE）：
在原始ASPE的基础上添加三个随机数和一个随机置换π（安全性↑）
在原始d维数据的基础上添加三个随机数转化为d+3维，然后经过一个d+3维的置换，再根据划分向量进行划分，使用密钥M1 M2加密

方案内容

朴素方案：

每个数据对象生成8个32维加密向量，每个查询请求生成8个陷门；
具体来说，一个数据集中含n个数据对象，每个数据对象的格式为（二维坐标数据，关键字数据），查询请求格式为（二维查询坐标，查询关键字，查询范围）
方案流程：
1)密钥生成:
生成的数据都是36+m维的（因为扩展置换后的向量为32+1+m+3个随机数=36+m维）
2)数据加密：
根据二维坐标所在的进行区域确定该坐标对应的8位geohash码（若不满8位，则后面位置0来凑够8位），然后将8位geohash码根据base32转化为8维十进制向量（里面的十进制）
①根据二维坐标生成8位geohash码
②根据base32转化为8维十进制向量，
③对于8个geohash码，每个码都初始化为32位0，然后将该位码对应十进制位上的值置为1，所以32位里只有一位是1其他都是0
④将关键字数据转化为m维向量，将存在的关键字位置1
⑤生成向量
⑥按照EASPE进行扩展加密，得到36+m维密文向量

3)陷门生成:和数据加密类似
4)查询阶段：看最后是否τ=8，即密文的geohash码和查询的geohash码一一对应则匹配成果，返回其标识符
评价：
这套朴素方案对每个数据对象和每个查询请求分别生成8个密文向量和8个查询陷门，存储开销和计算开销太大，需要进一步改进，但是安全性足够

改进方案：

将朴素方案中的8个32维向量转化为40维空间向量
1)密钥生成:
生成的数据都是44+m维的（因为扩展置换后的向量为40+1+m+3个随机数=44+m维）
2)数据加密：
①根据二维坐标生成8位geohash码
②根据base32转化为8维十进制向量，
③把每一维都转为5位二进制向量，
④最后生成8*5=40维二进制向量

3)陷门生成:和数据加密类似
4)查询阶段：看最后是否τ=8，即密文的geohash码和查询的geohash码一一对应则匹配成果，返回其标识符

评价：

每个数据对象和查询请求分别生成一个密文向量和陷门，降低存储和计算开销

思考：

①用户在为二维坐标生成geohash码时，具体生成几位hash码如何确定？总是根据查询范围动态计算的话开销很大？不动态的话是设置一个默认值吗？
②这个方案只适合查询范围正好是geohash码的位数对应的查询范围吧？如果相差过大不好划分位数，而且查询效率也不一定很高？