加密数据库模糊查询

最新推荐文章于 2024-09-24 18:02:25 发布

牛三金

最新推荐文章于 2024-09-24 18:02:25 发布

阅读量637

点赞数 1

分类专栏： SQL 文章标签：数据库 java 开发语言

本文链接：https://blog.csdn.net/niujinya/article/details/128340761

版权

SQL 专栏收录该内容

3 篇文章 0 订阅

订阅专栏

一、概念陈述

随着数据安全性的增加，很多数据公司面临数据保护的问题，比如一些商家会存储大量的私人信息在SQL或者NOSQL中，而需要考虑数据存放位置的安全性，以及传输过程的安全性，在现实情况中，基本没有完全可信的存储空间和传输通道，那么就需要一种更好的方案去解决这个问题，比如密态数据库，所有数据都用密文进行加密。但需要同样满足“可查”。最基本的方式是精确查询，即“王五”，“王五”的相关数据，这样基本很简单就能完成，但在数据库中更重要的功能是模糊查询，即“%王%”，所有和“王”有关的数据都被索引出来。

ps：目前我认为，这个问题不能考虑统计攻击的问题，即是基于非对称加密的查询也无法抵抗，即每次查询的数据记录一下，底层的密文很容易被攻破。所以密态数据库主要是抵抗数据盗取。

二、调研方案

方案1

我们先来看看第一个做法，将所有数据加载到内存中进行解密，这个如果数据量小的话可以使用这个方式来做，这样做既简单又实惠，如果数据量大的话那就是灾难，我们来大致算一下。一个英文字母(不分大小写)占一个字节的空间，一个中文汉字占两个字节的空间，用DES来举例，13800138000加密后的串HE9T75xNx6c5yLmS5l4r6Q==占24个字节。

方案2

对密文数据进行分词组合，将分词组合的结果集分别进行加密，然后存储到扩展列，查询时通过key like '%partial%'，这是一个比较划算的实现方法，我们先来分析一下它的实现思路。

先对字符进行固定长度的分组，将一个字段拆分为多个，比如说根据4位英文字符（半角），2个中文字符（全角）为一个检索条件，举个例子：

ningyu1使用4个字符为一组的加密方式，第一组ning ，第二组ingy ，第三组ngyu ，第四组gyu1 … 依次类推。

如果需要检索所有包含检索条件4个字符的数据比如：ingy ，加密字符后通过 key like “%partial%” 查库。

我们都知道加密后长度会增长，增长的这部分长度存储就是我们要花费的额外成本，典型的使用成本来换取速度，密文增长的幅度随着算法不同而不同以DES举例，13800138000加密前占11个字节，加密后的串HE9T75xNx6c5yLmS5l4r6Q==占24个字节，增长是2.18倍，所以一个优秀的算法是多么的重要，能为公司节省不少成本，但是话又说回来算法工程师的工资也不低，所以我也不知道是节省成本还是增加成本，哈哈哈…你们自己算吧。

回到主题，这个方法虽然可以实现加密数据的模糊查询，但是对模糊查询的字符长度是有要求的，以我上面举的例子模糊查询字符原文长度必须大于等于4个英文/数字，或者2个汉字，再短的长度不建议支持，因为分词组合会增多从而导致存储的成本增加，反而安全性降低。

大家是否都对接过淘宝、拼多多、JD他们的api，他们对平台订单数据中的用户敏感数据就是加密的同时支持模糊查询，使用就是这个方法，下面我整理了几家电商平台的密文字段检索方案的说明，感兴趣的可以查看下面链接。

淘宝密文字段检索方案

拼多多文本检索方案

京东

方案3

我们接下来看看优秀的做法，此类做法难度较高，都是从算法层面来考虑，有些甚至会设计一个新算法，虽然已有一些现成的算法参考，但是大多都是半成品无法拿来直接使用，所以还是要有人去深入研究和整合到自己的应用中去。

从算法层面思考，甚至会设计一个新算法来支持模糊查找

这个层面大多是专业算法工程师的研究领域，想要设计一个有序的、非不可逆的、密文长度不能增长过快的算法不是一件简单的事情，大致的思路是这样的，使用译码的方式进行加解密，保留密文和原文一样的顺序，从而支持密文模糊匹配，说的比较笼统因为我也不是这方面的专家没有更深一步的研究过，所以我从网上找了一些资料可以参考一下。