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，所以还不明确这些语句的作用。