加密SQLite

让我们首先介绍现有解决方案的简要特征：

> sqlite标准(商业)SEE扩展 – 我不知道它如何在内部工作以及它如何与提到的移动平台合作.
> System.data.sqlite(仅限windows)：完整DB,ECB模式的RC4加密.它们也会对DB头进行加密,偶尔会有(0.01％几率)导致数据库损坏.*)其他优势：它们使用SQLite合并分发.
> sqlCipher(openssl,即几个平台)：可选加密方案.他们加密整个数据库. CBC模式(我认为),随机IV矢量.因此,他们必须修改页面参数(大小保留空间以存储IV).他们意识到与未加密读取数据库标头有关的问题,并尝试引入变通方法,但解决方案并不令人满意.另外一个缺点：他们使用SQLite3源代码树. (另一方面 – 其他功能 – 启用其他功能,即使用特殊编译指示对加密参数进行微调.)

根据我自己的分析,我认为以下可能是一个不会遇到上述问题的好解决方案：

>加密除DB头之外的整个DB.
> ECB模式：听起来有风险,但在简要查看数据库格式后,我无法想象如何利用这种攻击进行攻击.
> AES128？
>在sqlite合并之上实现(类似于system.data.sqlitE)

我想讨论这种加密方案的可能问题.

*)由于sqlite读取DB头而无需解密.由于RC4(流密码),这个问题将在第一次使用时出现. AES会更加危险,因为每个“实时”数据库迟早都会面临这个问题.

EDITED – 基于VFS加密的案例

上述方法使用SQLite.org认可的基于编解码器的方法.它是一组3个回调,最重要的是这个：

void *(*xCodeC)(void *iCtx,void *data,Pgno Pgno,int mode)

此回调在sqlite自行决定时用于加密/解密从磁盘读取/写入的数据.数据逐页交换. (页面是512 By的倍数.)

替代选项是使用VFs. VFS是一组用于低级OS服务的回调.其中有几个与文件相关的服务,例如XOPEN / xSeek / xRead / xWrite / xClose.特别是,这里是用于数据交换的方法

int (*xRead)(sqlite3_file*,void*,int iAmt,sqlite3_int64 iOfst);
int (*xWritE)(sqlite3_file*,@R_696_2942@,sqlite3_int64 iOfst);

这些调用中的数据大小范围从4 By(常见情况)到DB页面大小.如果你想使用块密码(还有什么用？),那么你需要组织底层块缓存.我无法想象一个与sqlite内置事务一样安全且高效的实现.

第二个问题：VFS实现依赖于平台. AndroID / iOS / WP7 /桌面都使用不同的源,即基于VFS的加密必须逐个平台地实现.

下一个问题是一个更微妙的问题：平台可能使用VFS调用来实现文件锁定.这些用途不得加密.此外,不得缓冲共享锁.换句话说,VFS级别的加密可能会危及锁定功能.

EDITED – 基于VFS加密的明文攻击

我后来意识到这一点：DB头以固定字符串“sqlite format 3”开头,并且头部包含许多其他固定字节值.这为已知的明文攻击(KPA)打开了大门.

这主要是基于VFS的加密问题,因为它没有DB头被加密的信息.

System.data.sqlite也有这个问题,因为它加密(RC4)也是DB头.

sqlCipher用盐覆盖hdr字符串,用于将密码转换为密钥.此外,它默认使用AES,因此KPA攻击没有危险.