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，所以還不明確這些語句的作用。