加密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*,const void*,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攻击没有危险.

解决方法

关于’问题’你看到：

>您不需要重新实现文件系统支持,您可以包装默认的VFS.所以没有锁或平台依赖的问题.> SQLite的默认操作系统后端也是VFS,除了你添加之外,没有使用VFS的开销.>您不需要块缓存.当然,当它要求只有4个字节时你必须读取整个块,但是不要缓存它,它将永远不会被再次读取. SQLite有自己的缓存来防止这种情况(寻呼机模块).

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!