CN1588366A - 密文数据库检索技术 - Google Patents

Abstract

此项发明基于目前常用的PKI体系，在不改变数据库管理系统内部运行机制的前提下，通过程序逻辑实现了密文数据库，并在一定程度上保持了数据库原有的查询检索功能。为了保证密文数据在不解密的情况下能够被检索出来，日期、数字类型的数据需要按照一定的规则转换成字符，并且加密使用的分组密码算法需要进行一些改造。

Description

密文数据库检索技术

技术领域

本发明属于计算机软件相关领域，是加密技术在数据库中的应用。

背景技术

目前，大型关系型数据库管理系统都具备一整套完善的安全管理手段，包括识别角色权限、访问控制、安全审计等功能。其中的角色权限管理已经相当完善，基本能够满足权限分配的需要；访问控制已经精确到字段级，达到关系型数据库管理的最小粒度。

尽管数据库管理系统本身的安全措施已经相当完备，但是仍然无法完全解决数据安全的需求。业务数据管理的安全层次与数据库管理系统的安全层次往往不一致，数据库管理系统中具有超级权限的管理员往往不具备业务数据管理的超级职能。数据安全不仅要抵抗来自网络黑客的安全威胁，还要防止来自网络内部，特别是数据库管理员的安全威胁，而目前的数据库管理系统安全体系，几乎不能对数据库管理员采取任何安全限制。若要满足业务数据的安全需要，必须在现有数据库管理系统之外，建立一套符合业务数据安全需要的新的安全体系，在新的安全体系中对数据库中的敏感数据进行加密处理，以阻断来自数据库管理员的安全威胁。

发明内容

检索的目的是要从原文中查找特定的词，密文检索希望在不解密的情况下在密文中找到检索词在原明文中的位置，由于原文在加密过程中经过了充分的混合和扩散，原文中的字、词都是与周围字、词一起加密的，这些字、词相互影响，与检索词单独加密形成的密文没有对应关系，因此，无法通过直接比对密文与检索词密文得到检索词的位置。

为了保证在密文数据在不解密的前提下被检索出来，必须保证相同的明文字加密后能够得到相同的密文。对于IDEA分组加密算法，如果密钥相同，完全相同的明文分组会得到相同的密文，不同分组内的明文，因为受周围其它字、词的影响，明文与密文完全没有对应关系。因此，保证密文检索的前提是，一个64位分组只处理一个明文字。如果明文以Unicode的形式编码，一个明文字对应2个字节，即16位二进制数，因此加密前首先要将这个16位二进制数转换成一个64位分组。

转换的方式有多种，最简单的方式是：将1转换成1111，将0转换成0000，这样，每个64位分组就与一个明文字相对应。还可以有其它可能的转换方式，如：末尾添1或末尾添0；将16位二进制数重复4次；添加一个扩展密钥，密钥与16位二进制数计算得到一个64位分组，等等。

检索时将查询词分解成单有字，将每个字转换成Unicode编码格式，然后将这些16位二进制数按照上面的办法转换成64位分组，使用加密原文相同的密钥进行加密运算，得到查询词密文。将查询词密文提交到查询服务器，与原文密文进行比对，就可以得到查询结果。

二进制数据的传输、存储和比较都不十分方便，实际应用时可以采用Base64编码，将二进制数转换成字符型数据。

具体实施方式

要加密的数据可能有各种数据类型，加密后经过Base64编码，统一变成字符型数据，因此密文数据库的密文字段的数据类型可以统一定义为字符类型。如果数据只在一定时间内需要保密，过了保密期限数据要以明文形式存储，或者同一个数据表中只有部分记录有保密要求，其它记录需要存储明文，就需要对同一个数据在数据表中建明文和密文两个字段，明文字段采用明文需要的数据类型，密文字段用字符类型。在同一时刻的同一条记录，明文字段和密文字段只能由一个被填充。

1、加密

加密前首先要生成对称密钥(以下简称密钥)，为了防止来自网络内部，尤其是系统管理员的安全威胁，密钥应该在客户端生成。

加密前首先要将数字、日期等数据统一转换成字符型数据。

日期型的数据转换起来比较简单，可以直接将日期格式化为字符串，如：“2004-05-0121:30:05”，注意格式转化中年、月、日、时、分、秒位数要添满，“5月”要用“05月”，时间用24小时格式，以保证检索时可以按位比较。

数字型数据的转换比较复杂，需要处理正负号、小数点、指数等。首先要处理正负号，正号不能忽略，要转换成“1”，负号转换成“0”；然后写指数部分，指数的位数要固定，根据数据的范围选一个合适的长度，位数不足的要在前面补零；然后是底数的小数点以后的部分。

假设指数部分取三位，转换举例如下：

365       ＝  +0.365×10+003      转换成       11003365

-365.056  ＝  -0.36556×10+003    转换成       01003365056

0.000365  ＝  +0.365×10-003      转换成       10000365

加密前进行转换的目的是为了保证检索时可以按照字符位进行比较，通过比较字符，得到数值或日期的大小。

将转换后的字符串分解成单字，对每个字单独进行加密处理，将单字密文合并后得到密文。

将密钥用自己的公开密钥加密得到密钥密文。

将密文与密钥密文保存到密文库，完成加密操作，见图1。

2、密文检索

密文检索时首先要从密文库中下载密钥密文，然后用自己的私有密钥解密，得到密钥。

按照与明文加密时相同的方法将检索词转换成字符，然后将字符拆分位单字，用密钥对每个字单独进行加密处理，将单字密文合成检索词密文，提交到密文库进行检索，见图2。

由于明文字符与密文分组有一一对应关系，对于字符型数据常用的“等于”或“包含”类查询，可以保持原来的查询语句不变，直接在密文库中查找检索词密文即可。对于数字类型和日期类型常用的“大于”或“小于”等查询条件，由于加密后明文中的大小关系与密文字符串的大小关系不一致，明文所具有的数值大小比较在密文中不复存在，因此，需要对检索条件进行重构，使其能够完成密文数值大小的比较。

重构检索条件时首先将“大于等于X”拆分为“大于X”或“等于X”两个检索条件，同样将“小于等于X”拆分为“小于X”或“等于X”两个检索条件。“等于”查询条件可以直接进行密文比对。

由于加密前在对日期和数字型数据进行转换时已经为检索作了准备，这些数据的大小比较与转换后的字符串按位比较可以取得一致，因此，密文检索条件的重构可以按照每个明文字符对应的密文分组为单位进行。以“大于0.000365”为例(转换后为10000365)：

首先处理符号位，体现在检索条件中为“第一个密文分组为1的密文”(限制查询结果为正数)；然后是指数符号位，体现在检索条件中为“第二个密文分组为1的密文或0的密文”(对于查询结果是否大于1没有限制)。

然后是数字的比较，可以按位进行：“大于0”体现在检索条件为“这个密文分组可以是0至9的任何一个数字的密文”，“大于3”体现在检索条件为“这个密文分组可以是3至9的任何一个数字的密文”，其余以此类推。

最后的一位(大于5)的检索条件为“这个密文分组可以是6至9的任何一个数字的密文”或“这个密文分组是5的密文且后面还有其它数字(即：密文比查询的密文位数长)”。

组合以上检索条件可以查询得到“大于0.000365”的数。

3、解密

解密时首先要从密文库中下载密钥密文，然后用自己的私有密钥解密，得到密钥。然后下载密文，用密钥解密成明文字符，将解密后的明文字符串按照与加密时相反的规则转换成原来的数据类型，见图3。

附图说明

图1：数据加密流程。

图2：密文检索流程。

图3：数据解密流程。

Claims (2)

1.为适合密文数据库检索对分组加密算法的改进，其特征是将单个字对应的二进制数进行扩展，达到与加密算法分组位数相同的长度，在密钥相同的条件下，相同明文字的密文相同，不受上下文中周围其它字的影响，通过比检索词的密文，实现不解密条件下的数据库查询检索。

2.为实现能够通过密文比较明文大小而对数值型、日期型等数据类型进行的字符串转换，其特征是转换后的字符串可以按照字符位比较得到原明文数据的大小，通过查询语句重构可以实现不解密条件下的数据库数值型、日期型等字段的比较查询。