面向CryptDB的用户身份验证方案

薛金红, 田秀霞, 宋 谦, 田福粮

(上海电力大学 计算机科学与技术学院, 上海 200090)

随着云计算的迅猛发展,越来越多的企业、个人将数据迁移到了云端,并利用云数据库管理系统数据。与传统数据库相比,云数据库的可扩展性与灵活性较好,效率更高,但在数据安全保障方面存在很大不足。为了解决数据存储的安全问题,一般将数据加密后存储,即使攻击者获得数据访问权限,仍能保证数据的机密性。如果使用传统加密算法(AES,3DES)加密数据,用户每次检索、计算和分析数据都必须把密文传回客户端,进行解密后再做处理,势必会向客户端传回大量无用密文,使得数据库只起到存储介质的作用,浪费了其本身的能力资源,显著降低了效率。直接在加密数据上执行数据库操作,是在密文数据库进行查询处理的另一途径。

2011年PAPO R A等人[1-2]提出的CryptDB是一个经典的基于可信中间代理、不可信数据库系统的密文数据库。典型的CryptDB系统由应用程序、数据库代理、未修改的数据库系统3部分组成,其中间代理充当媒介,操控、改写收到的SQL指令和数据库返回的结果集合,数据库系统中增加CryptDB用户自定义函数(User Define Function,UDF)模块,辅助实现复杂密文操作(如数据聚合、两列连接、关键字搜索等)。最重要的是,CryptDB是分离式架构,易于部署,兼容性好,非常适用于云数据库应用场景。

然而,CryptDB系统中密钥信息是以明文形式存储在代理服务器,安全性较低。本文提出通过用户口令加密密钥信息来增强密钥安全性,同时以中间代理间接验证用户身份这一方法,有效地管理了代理服务器资源。

1 研究现状

1978年RIVEST R L等人[3]提出了全同态加密(Fully Homomorphic Encryption,FHE),尝试在加密数据上进行计算。2009年GENTRY C[4]基于理想格理论设计出了第一个全同态构造,后续尝试优化以改善其性能[5]。但由于其公钥太大,生成时间长,效率低下,不具有实用价值,用全同态加密解决密文查询问题还有待进一步的研究。

CryptDB以洋葱加密方式[1-2]拆分明文列为多密文列,每个密文列承担不同的运算操作功能,并组合多种支持数据库操作的密码学技术(如随机加密、确定性加密、保序加密、可搜索加密及Join等),每个洋葱逐层嵌套加密,使得数据库的安全性从里到外逐层增强、功能逐层减弱,最大化保证数据的安全性;而且,与明文数据库相比,CryptDB数据库开销小,吞入量下降少,实现了系统安全、功能和性能三者之间的兼顾和平衡。

TU S等人[6]在CryptDB的基础上设计了Monimi,引入根据查询负载特点选择数据库物理布局的设计器和运行时选择高效查询计划的计划器,并结合多种优化方法,如行预计算、空间高效加密、组同态加密等,提高了查询执行效率。LI J等人[7]提出了轻量型的密文数据库L-EncDB,采用组合格式加密(Format-Preserving Encryption,FPE)、模糊查询(Fuzzy Query Encryption,FQE)和保序加密(Order-Preserving Encryption,OPE)解析SQL查询请求,但系统过度依赖函数实现功能,可扩展性差。陈鹤等人[8]针对CryptDB洋葱加密方式的不足提出了优化改进模型Crypt-JDBC密文数据库,由JDBC充当中间组件,将密文列分为主列和辅助列(保序列、搜索列、等值连接列)。主列采用双向加密方法,可以解密出明文;辅助列采用单向加密方法,不可解密,支持各类运算操作。但取消了对用户自定义函数的依赖,多层嵌套式密文不适用于该模型。BURKHALTER L等人[9]提出了加密时序数据库TimeCrypt,是专为时间序列数据量身定做的,支持在大容量加密时序数据上的快速统计查询,而且用户可以根据预先定义的访问策略以加密方式限制查询和数据访问范围。

2 方案设计

PAPO R A等人[1-2,9]开放了CryptDB项目源码,其前端用Mysql-Client替代,后端用Mysql-Server替代,数据库代理由Mysql-Proxy充当。Mysql-Proxy可通过lua脚本接口调用C链接库扩充逻辑,实现复杂功能。为方便描述,下面将Mysql-Client简称为客户端,Mysql-Proxy简称为代理,Mysql-Server简称为数据库。

2.1 问题描述

客户端、代理和数据库三者之间的交互分为3个阶段,分别为连接认证、查询处理和断开连接。

2.1.1 连接认证

客户端、代理及数据库连接认证流程步骤如图1所示。

图1 客户端、代理和数据库连接认证流程

(1) 客户端向代理发起TCP连接,建立传输通道。

(2) 代理向数据库响应初始握手包(包括协议版本号、数据库软件版本、服务器授权信息及服务器权能标志等信息)。

(3) 客户端回应登录验证报文(包括账号、密码、默认数据库名称及编码方式等信息)。

(4) 代理向数据库发出连接请求。

(5) 数据库验证账号、密码,并响应验证结果。

(6) 若验证成功,代理读取本地映射表,在内存中加载SQL语句改写逻辑,并向客户端发送OK Packet;若验证失败,代理向客户端发送ERR Packet。

2.1.2 查询处理

连接成功后,当客户端发出明文查询请求时,代理解释、重写SQL语句,加密明文数据后转发到数据库;当数据库返回密文结果集合后,代理解密数据并返回明文结果集合到客户端。特别是当查询处理是数据库定义(Data Definition Language,DDL)操作时,需要更新本地映射表。如当创建表时,先将明文表名与密文表名、洋葱加密存储列表及对应明文列名,密文列名、洋葱层对应密文查询算法使用密钥存入本地映射表,再将改写后的SQL转发到数据库,生成密文表。具体查询处理过程如图2所示。

图2 查询处理流程

图2左侧student表是明文表结构,右侧table_1表是student表对应生成的密文表结构。在表table_1中,C1开头的列是明文列Id拆分运算属性生成的密文列,C2开头的列是明文列Name对应密文列,当前Id列和Name列的DET洋葱都处于最外层。客户端发出查询请求:select id from student where Name=“bear”,CryptDB处理查询流程如下。

(1) Name列为相等条件判定,为调整其DET洋葱到DET层,代理向数据库发出查询请求:UPDATE table_1 SET C2-Eq = DECRYPT_RND(KT1,C2,Eq,RND,C2-Eq,C2-IV)。其中列C2-IV是明文列Name随机层加密使用初始参数盐值(IV)的值。

(2) 代理改写查询请求后转发到数据库:select C1-Eq,C1-IV from table_1 where table_1 =x2..7,其中x2..7是“bear”依次用K(T1,C2,Eq,DET)和K(T1,C2,Eq,JOIN)作为密钥加密得到的值。

(3) 数据库返回密文结果集合,代理依次用K(T1,C1,Eq,JOIN),K(T1,C1,Eq,DET),K(T1,C1,Eq,RND)作为密钥逐层解密C1-Eq值,得出23后返回到客户端。

2.1.3 断开连接

客户端向代理发出TCP断开请求后,代理向数据库发出TCP断开连接、销毁关联对象、释放系统资源指示,本次连接断开。

2.1.4 问题分析

由以上对数据库客户端、代理、数据库三者间交互过程的描述可知:支持密文查询处理密码学协议使用密钥信息以明文形式存储在代理服务器;连接验证过程中代理没有直接验证用户身份,自动在内存中加载查询语句改写方式。

若攻击者获取数据库账号、密码、代理IP及端口,即可成功连接数据库,获得数据访问权限,就存在很大安全隐患。本文采用用户口令加密密钥信息,对系统加以改进,改进后系统模型如图3所示。需要注意的是,此处的用户指所有数据拥有者,或者程序高级管理员。

图3 改进后系统

2.2 用户身份认证方案

用户身份认证方案包括3个环节,分别为用户口令传递、用户口令初始化和用户口令更新。

2.2.1 用户口令传递

用户口令由用户设置,需从客户端传递到代理。用户口令传递方式有两种:一是增加一条独立协议,传递用户口令;二是扩展官方认证报文,添加用户口令字段。

方式1独立于Mysql官方通信协议,增加专门协议传递用户口令,灵活性高;方式2扩展Mysql官方用户认证报文,连接认证流程无需变动。因为方式2代码改动量小,易于实现,故本文选用方式2。Mysql-Client 4.0以上版本认证报文遵守HandshakeResponse41协议,扩展后协议记为HandshakeResponse42,结构如下。

capability flags,CLIENT_PROTOCOL_41 always set

max-packet size //最大包

haracter set //字符编码

string[23] reserved (all[0]) //保留字段

string[NUL] username //用户名

if capabilities & CLIENT_PLUGIN_AUTH_LENENC_CLIENT_DATA {

lenenc-int length of auth-response

string[n] auth-response

} else if capabilities & CLIENT_SECURE_CONNECTION {

length of auth-response

string[n] auth-response

} else {

string[NUL] auth-response

}

if capabilities & CLIENT_CONNECT_WITH_DB {

string[NUL] database

}

if capabilities & CLIENT_PLUGIN_AUTH {

string[NUL] auth plugin name

}

if capabilities & CLIENT_CONNECT_ATTRS {

lenenc-int length of all key-values

lenenc-str key

lenenc-str value

}

string[n] cryptdb-key

string[n] old-cryptdbkey

string[n]是可变长类型字符串,表1是HandshakeResponse42协议相对HandshakeResponse41协议的新增字段,用于实现用户口令传递及更新。

表1 HandshakeResponse42协议新增字段

2.2.2 用户口令初始化

客户端首次连接代理,需要创建一个关联数据库。当创建第一张表时,使用默认用户口令加密密文查询算法,使用密钥后再存储,使用户与用户口令建立唯一对应关系。如代理启动服务后,终端下输入以下命令启动客户端,连接代理:./mysql -u root -p200811 -h 127.0.0.1 -P 3307 --cryptdb_key=xxxxxx…xx。

其中xxxxxx…xx是默认用户口令值。

代理收到连接请求,客户端直接返回OK Packet。成功连接后,客户端依次发出以下查询请求:

(1) create database cryptdb_test; //创建数据库cryptdb_test;

(2) use cryptdb_test;

(3) create table student(Id int,Name Varchar(10));//创建表student。

查询请求(3)中代理拆分明文Id列生成密文列为C1-IV,C1-Eq,C1-Ord,C1-Add。拆分Name列生成密文列为C2-IV,C2-Eq,C2-Ord,C2-Add,同时由主密钥衍生密钥种子值。最后向数据发出以下查询请求:

create table_1 (C1-Eq BIGINT unsigned,C1-Ord BIGINT unsigned,C1-Add VARBINARY(256),C1-IV BIGINT(8) unsigned,C2-Eq VARBINARY(48),C2-Ord BIGINT unsigned,C2-Search VARBINARY(256),C2-IV BIGINT(8) unsigned)AUTO_INCREMENT=0 ENGINE=InnoDB。

数据库执行创建表操作,返回执行结果,代理解密后,返回执行结果到客户端,至此用户口令成功初始化。

2.2.3 用户口令更新

用户口令存在安全期限,长期不更换会给系统带来一定的风险,为此需要定期更新用户口令。在扩展认证报文HandshakeResponse42协议中,当old-cryptdbkey字段值不为空时,old-cryptdbkey字段代表旧用户口令,cryptdb-key字段代表新用户口令,用老口令解密得出密钥信息,再使用新用户口令加密密钥信息后存储在本地,至此用户口令完成更新。如代理启动服务后,终端下输入以下命令启动客户端,连接代理:

./mysql -u root -p200811 -h 127.0.0.1 -P 3307 --cryptdb_key=xxxxxx…xx --old_cryptdbkey=yyyyyy…yy。

其中,xxxxxx…xx是新用户口令值,yyyyyy…yy是老用户口令值。

代理收到连接请求,向数据库转发连接请求,数据库验证结果OK,代理在内存中加载SQL语句改写方式,在此过程中用xxxxxx…xx解密密钥信息,若解密成功,再用yyyyyy…yy加密密钥信息后存储在本地,代理再向客户端发出OK Packet,至此用户口令成功更新。

3 实 验

实验在Ubuntu12.04.1系统环境下进行,Mysql-Client版本5.5.54,Mysql Proxy 版本0.8.4,Mysql server版本5.5.54,开发工具Qt Creator 3.4.1。

3.1 安全性分析

使用用户口令加密密钥信息后,密钥信息以密文形式存储在代理服务器外存,即使攻击者得到加密的密钥信息,密钥安全性仍有一定保证。同时,在应用连接代理过程中,加载查询语句改写方式中用户口令要解密密钥信息,达到了间接验证用户身份的效果。因此,本方案增强了CryptDB密钥管理安全性,提高了系统整体的安全性。

3.2 时间复杂度分析

改进后的系统记为CryptDB-1,以下实验对比了CryptDB与CryptDB-1的执行效率。以简单增加表,插入数据为例,分别对比执行5条,10条,20条,50条,60条语句的时间消耗。其中图4描述了多次Create的总时间消耗情况。表2描述了执行多次Create的单条平均消耗情况。

图4 执行多次Create消耗时间

表2 执行多次Create单次平均消耗时间 ms

由图4可以看出,创建表操作时,执行相同条数CryptDB-1比CryptDB总消耗时间长;由表2可以发现,随着Create执行次数的增加,CryptDB和CryptDB-1平均执行一条的消耗时间也随之增加,而且CryptDB-1比CryptDB平均执行一条的消耗时间要长。因此,创建表CryptDB-1比CryptDB的执行效率低。

图5描述了执行多次Insert的总时间消耗情况。表3描述了执行多次Insert的单条平均时间消耗情况。

图5 执行多次Insert消耗时间

表3 执行多次Insert单次平均消耗时间 ms

由图5可以看出,CryptDB和CryptDB-1执行多次Insert总消耗时间基本相同。由表3可以发现,随着执行Insert次数的增加,CryptDB和CryptDB-1平均执行一条的消耗时间都较短,同时CryptDB与CryptDB-1平均执行一条的消耗时间基本相同,所以插入数据时,CryptDB和CryptDB-1执行效率基本一致。

从上述实验数据可以看出,在Create操作上,CryptDB-1比CryptDB效率低,原因是CryptDB-1中增加了用户口令加密密钥信息环节,增加了时间消耗,使得系统效率降低。执行Insert操作时,内存中已加载SQL改写方式,所以Insert操作时CryptDB-1效率保持一致,同理,执行select,update,drop及delete操作时,CryptDB与CryptDB-1效率保持一致。

4 结 语

本文针对典型云密文数据库CryptDB中密钥信息以明文形式存储、安全性低的特点,提出了使用用户口令加密密钥信息后以密文形式再存储的方式,增强了密钥管理的安全性。当重新连接代理时,先解密密钥信息,再在内存中加载SQL语句改写方式,在此过程中,代理间接验证用户身份,有效管理了代理服务器资源的访问权限,显著

提高了CryptDB系统整体的安全性,是数据库技术与数据库代理技术一次积极的融合。