sqlite加密设计的缺陷与改进

概述  sqlite是 一个非常小巧的跨平台嵌入式数据库，它本身不提供加密功能，不过设计者明显也考虑了加密的方案，我们在源码中可以找到两个预留的加密接 口：sqlite3_key和sqlite3_rekey，可以通过实现这两个接口来达到加密的目的。         如何加密，已经有很多文章描述，可以参考:《 SQLite 数据库加密的一种解决方案 》         我这里要说的是这种方法的缺陷和改进

sqlite是 一个非常小巧的跨平台嵌入式数据库，它本身不提供加密功能，不过设计者明显也考虑了加密的方案，我们在源码中可以找到两个预留的加密接 口：sqlite3_key和sqlite3_rekey，可以通过实现这两个接口来达到加密的目的。

如何加密，已经有很多文章描述，可以参考:《 SQLite 数据库加密的一种解决方案 》

我这里要说的是这种方法的缺陷和改进的方法（测试sqlite版本v3.5.6）；

加密函数的简要说明：

sqlite3_key的输入参数有三个：一个是sqlite3的指针，二、三分别是密码的指针和数据长度；

从第一个参数，我们可以看出，必须先用sqlite3_open获取一个sqlite3指针，才能调sqlite3_key设置密 钥；

问题描述：

sqlite3_open的目的是打开database，openDatabase的过程中会去读取和解析db文件的头信息；

（我们用二进制查看工具（比如ultraEdit）打开数据库文件时，会在最前面发现 “sqlite format 3...”一些可读的信息，前面这100个字节就是sqlite数据文件头信息。）

openDatase的一个主要功能就读取这些头信息，其中有比较重要的database的page size， 这个参数用第16、17字节表示；在未加密的情况下，我们观察这个值一般是0400，表示数据库的page size是1024；

问题出现了：我们已经知道，加密设置是在openDatase之后，如果数据已经加密，opendatase必然拿不到正确的page size等信息，那么为什么加密的方法使用时没有出错呢？

因为此时数据库第16、17字节一般会是乱码，当pagesize读出不是512的整数倍，或者大于某个值时，opendatase会 默认把page size当1024处理，而这种做法一般也都没有问题（前提是很多数据库的 pagesize确实是1024 ）；但这种做法并不安全，存在两个风险：

风险一：如果数据库的pagesize不是1024，而是2048，加密后数据库还能打开吗？

风险二：如果数据库加密后的16、17字节正好是512的整数倍，那就会被误认为是pagesize， 导致数据库无法打开 （这种数据已经试验出，并证明一定会出错 ）；

解决方案：

这种问题，实际上是因为sqlite代码中没有充分考虑这种pagesize在加密后读取的问题，解决方法有两个：

方案一：（彻底解决方案）修改sqlite源码，使opendatase读取的pagesize无效， 在设置好数据库密钥以后，第一次读取数据时重新计算pagesize；

方案二：（针对加密的修补方案）修改sqlite3_key的加密实现，在设置密钥时，解密读取数据库 的头信息，读取解密后的pagesize，再把这个正确的pagesize设置回去；

经过比较分析，我选用了第二种方案，sqlite源码如果修改，就面临sqlite升级的维护，而只修改加密实现部分也能解决问题，这也不影响原来 sqlite的实现，不过这个问题得向sqlite的开发小组提一下；

其它问题：

为什么pagesize读取不对，就会导致数据库打开失败？

pagesize决定数据会从文件中读取多少字节进行page解析，第一个page尤其重要，它存放了数据库里面的各种table的 信息，如果pagesize不对，sqlite将无法解析到底有那些表，直接导致数据打开失败；即使侥幸打开成功，以后取数据也会出问题；

最新的sqlite版本有没有解决这个问题？

目前sqlite更新频率很高，最新的是3.6.11，还没验证是否已经解决，不过发现lockBtree的代码中发现新增了一些重新设置 pagesize的语句，但重新设置后没有重新读取page，所以还不明确这些语句的作用。

总结

以上是内存溢出为你收集整理的sqlite加密设计的缺陷与改进全部内容，希望文章能够帮你解决sqlite加密设计的缺陷与改进所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。