基于Android平臺的SQLite數據庫加密研究

何文才 馬鵬斐 劉培鶴 楊亞濤 肖超恩

1(西安電子科技大學通信工程學院 陜西 西安 710071)2(北京電子科技學院電子與通信工程系 北京 100070)

0 引 言

Android操作系統在現今的移動領域發展中占據著無法替代的地位。據2017年第一季度移動通信消費者指數顯示，在智能移動終端中，Android操作系統所占的市場份額占智能移動設備銷量的87.2%，該比重仍在持續上漲[1]。嵌入式數據庫SQLite作為Android平臺數據存儲的主要方式，有消耗資源小、存取效率高等優點。然而，在原生SQLite中數據以明文形式存在，導致存于其中的數據會輕易地被人用文本編輯器查看。本文針對SQLite這一缺點，在Android平臺下，通過對AES算法進行性能優化，設計一個可靠有效的SQLite數據庫加密系統。

國內外很多學者也對SQLite加密進行了研究。文獻[2]通過實驗驗證了AES-256算法在SQLite上的可行性，解決了Android平臺下SQLite明文存儲的安全問題，但沒有對該算法的性能進行分析。文獻[3]提出的XXTEA加密方案，將攻擊所需的明文數量上升為280，提高了SQLite的安全性，但沒有考慮Android平臺下的工作情況，加密速率不夠理想。文獻[4]針對64位處理器的Android操作系統，對AES-256進行優化，用運算速率的些許降低換來存儲空間減少、密碼強度的提升，但并沒有利用好Android系統多核的特點進行并行處理提升運算速率。在Android平臺下，這些對SQLite加密的研究，也都沒有考慮到密鑰安全問題。

本文針對目前Android平臺多核、存儲空間有限、對速率要求高等特點，提出了一個更為安全高效的SQLite加密方案。該方案在安全性較高的CTR模式下，運用優化的AES算法對SQLite文件并行加密。在密鑰擴展算法部分，通過對第一輪密鑰的分析處理，降低密鑰之間的耦合度，有效地抵抗了已知明文攻擊。輪變換中，狀態矩陣各行(列)進行分塊并行處理，采用多核多線程機制，很大程度地提升了加解密過程的運算速率。

1 相關技術

1.1 SQLite加密方式

SQLite數據庫是以文件的形式存在于Android源碼中。對其加密有兩種方式：將內容加密后寫入數據庫和對數據庫文件加密[3]。前者加密不夠徹底，加密后寫入、搜索將會是問題，故本文選擇相對安全可靠的對數據庫文件進行加密的方式。

SQLite源代碼沒有提供加密功能，卻保留了加密接口，供后續開發使用。加密接口包括sqlite3_key()、sqlite3CodecGetKey()、sqlite3_rekey()和sqlite3Codec-Attach()[4]。在本方案的實現中，用本文優化的AES算法來實現這些接口即可。其中，sqlite3CodecAttach()的實現相對復雜，流程圖如圖1所示。

圖1 sqlite3CodecAttach()函數流程圖

口令的來源有兩種，用戶創建賬號時自行設置的密鑰和主數據庫的密鑰。系統確定密鑰來源后，調用相應函數獲取口令，實現sqlite3CodecAttach()函數，繼而在sqlite3_key()中調用。

1.2 加密算法

根據Android平臺可利用硬件、空間資源有限的特點，本文采用優化的AES算法對其進行加密，以保證SQLite數據庫的性能和安全性。

AES加密算法加解密過程中密鑰相同，密鑰長度有128位、192位、256位三種。加密過程中，不同的密鑰長度擁有不同的加密輪次。AES屬于分組密碼，每次可以處理特定長度的塊數據[5]。

AES算法包括明文與初始密鑰“異或”、輪變換、密鑰擴展算法三個部分。其中，后兩部分相對復雜且有良好的優化空間。加密時，明文與初始密鑰“異或”后，對其執行輪變換操作。輪變換過程有字節替換(SubBytes)、行移位(ShiftRows)、列混合(MixColumns)、輪密鑰加(AddRoundKey)。輪變換過程中最后一輪沒有列混合步驟[4]。

字節替換是非線性變換的過程，用S盒取代“乘逆”、“仿射”運算，通過查表的方式實現字節替換。在AES-128中，每個表需要256字節，10輪就有160個S盒。Android平臺是允許這部分空間耗損的。而在AES-256中，S盒由原來的8×8變為16×16。如果使用標準AES的S盒查表實現，則每一張表需要65 536字節的存儲空間，10輪共需要160個S盒，占用資源太大，無法查表實現。因此，在空間資源允許的情況下，為了不降低運算速率，本方案選擇優化AES-128算法。

在標準的AES-128算法中，行移位過程是以字節為單位，“左移”N個單位的算法。其中，N為各字節所在行數。列混合部分是利用狀態矩陣與固定矩陣相乘來進行混淆。輪密鑰過程運用狀態矩陣和128位輪密鑰“異或”[6]。輪變換中，每一輪的輪密鑰由初始密鑰和密鑰擴展函數計算得出。密鑰擴展算法部分，將128位初始密鑰經過運算擴展出加解密過程所需的176字節的密鑰。四個字節為一個字，得到的前四個字作為AES-128算法加解密過程的第一輪密鑰。該過程總共需要11組密鑰，即10次輪變換密鑰和輪變換前“異或”操作的初始密鑰。

2 SQLite數據庫加密設計

常用的數據庫安全機制有：用戶身份認證、存取控制機制、數據加密、數據庫操作審計和攻擊檢測[7]。本方案主要從前兩個方面建立SQLite安全模型，如圖2所示。

圖2 SQLite數據庫安全模型

(1) 用戶使用應用程序客戶端并根據提示輸入正確的密碼，只有當系統通過用戶身份驗證將其識別為合法用戶時，用戶才能進入SQLite數據庫并對其進行操作。

(2) 為了避免一些惡意攻擊者繞過身份認證環節，直接打開SQLite數據庫竊取、篡改隱私信息，該模型采用整庫加密的方案。

(3) 一部分不法分子會試圖竊取合法用戶的認證口令，此安全模型將用戶口令單獨加密成密令，和密文一起存儲在本地數據庫，保護用戶口令安全。

經分析得出，SQLite安全性的強弱取決于加密算法的可靠程度。

用戶存取數據時，SQLite加解密的整體結構如圖3所示。

圖3 SQLite加解密過程

系統首先判斷用戶是否首次登錄；若是，用戶創建口令，系統口令經過MD5散列轉化為固定長度的輸出，作為優化AES加解密算法的初始密鑰K，并存儲在SQLite中；若不是，繼而判斷輸入口令是否正確，正確則進入系統，執行相應加解密操作。

3 AES算法的改進

3.1 密鑰擴展算法的改進

密鑰是加密算法中尤為重要的一部分。在AES的原始密鑰生成算法中，除了初始密鑰w0、w1、w2、w3之外，每個密鑰都是有先前的密鑰操作獲得的。假設知道其中任何一輪密鑰，即可破解全部密鑰，這會對數據安全造成極大的威脅。

針對這一問題，本系統采用一種改進的密鑰擴展算法方案，提高密鑰的安全性。改進的算法過程如下：生成一組與初始密鑰無關的4個字(w4,w5,w6,w7)作為第一輪輪密鑰。然后將每個字“左移”1位，與w4、w5、w6、w7做“異或”運算，再對結果進行原有AES密鑰擴展算法運算產生其他輪密鑰。改進后算法過程如圖4所示。

圖4 改進的密鑰擴展算法過程

性能分析：

設初始密鑰為n比特，窮盡密鑰攻擊最佳情況是1，即一次就猜中初始密鑰，最差情況是2n，即嘗試了密鑰空間所有的可能才得到正確密鑰。窮盡密鑰攻擊的平均復雜度是：

(1)

改進前，由式(1)計算出的復雜度為2127，而在算法改進后，該值提升為在2255～2511之間。以目前的計算能力，在有限時間內，完成這種窮盡搜索是幾乎不可能的事情。

改進的密鑰擴展算法降低了密鑰之間的耦合度，增強了密鑰生成階段的不可逆性，可有效抵抗窮盡密鑰攻擊。在第一輪、第二輪密鑰之間加上簡單的“移位”、“異或”操作，既可以有效防止窮舉攻擊，又可以不影響整體加密速率。就算攻擊者得到某一輪的密鑰，也無法直接推出初始密鑰和第一輪密鑰，很好地增強了密鑰的安全性。

3.2 輪變換優化

在AES-128算法中，10輪輪變換需160個S盒，一個S盒中的表需256字節。即一輪加密大約需要消耗的空間大小為256×160/1 000=40.96 KB，可見空間占有極少。這種用較低的空間消耗換取運算速率上的提升符合Android平臺的需要，故該過程不做變化。

標準AES算法中的運算是在確定狀態矩陣各行或各列都已經過每一步變換，才執行接下來的運算操作。本文研究的加密方案是工作在Android平臺下的，而目前Android手機的硬件環境都在四核以上。因此，可以利用這一硬件特點，在輪變換中使用并行計算來提高算法的計算效率。

經分析得知，SubBytes、ShiftRows變換都作用于行，MixColumns作用于列，AddRoundKey作用于每個元素。據此，可以對狀態矩陣進行分塊處理：在每一行字節變換后，繼續行移位操作；在每一列列混合后，進行AddRoundKey操作。用這種并行方式可以在每一行(列)運算時省去等待其他行(列)運算完畢的時間。以4核4線程為例，優化后的輪變換步驟如圖5所示。

圖5 改進的輪變換過程

性能分析：

由圖5可知，若SubBytes、ShiftRows、MixColumns、AddRoundKey過程各行(列)運算消耗時間分別為Ta、Tb、Tc、Td，標準AES-128算法輪變換消耗時為：

T128=4(Ta+Tb+Tc+Td)

(2)

改進后的輪變換消耗時間為：

(3)

理論計算可得，改進后的輪變換過程消耗的時間為改進前的1/4。擴展可得，對N核N線程的Android手機，使用該方案改進后的輪變換過程消耗時間為改進前輪變換消耗時間的1/N。實際測試中，由于受硬件平臺、環境、操作等因素的影響，測試結果不會和理論值一樣理想，但仍然可以很大程度地提升運算速率。

3.3 CTR模式下的并行運算

AES分組密碼算法的幾種基本工作模式中，支持并行計算的有ECB模式(電碼本模式)和CTR模式(計算器模式)[4]。前者在明文相同時每次加密所得的密文都是一樣的，容易在已知明文的情況下受到攻擊，安全性不強，故本方案采用CTR模式優化AES算法。

CTR模式下，分組明文可為任意長度，操作自由便捷，適用于運算速率的提高。其加解密流程分別如圖6、圖7所示。

圖6 CTR分組模式加密流程

圖7 CTR分組模式解密流程

由加解密示意圖可以看出，CTR模式下有一個自增的算子Tn，Tn用密鑰K和加密算法加密后的輸出，與明文塊“異或”得到密文。由于每次運算的算子Tn不同，相當于該模式下各分組加密時的密鑰不同。這彌補了ECB模式的不足，安全性極高。

本方案中，Tn為隨機產生的128位的計數器，n=1,2，…，q，每次用完自動加1。由于各明文分組輸入輸出沒有關聯，因此可以并行處理。本系統將明文按每塊128位分組。若最后一組不滿128位，則取最高有效length位，余下128-length位舍去。

本文研究的Android平臺應用層基于Java語言開發，通過創建線程池，運用多線程來完成并行處理。在本系統所使用的4核4線程的硬件環境下，每次執行4個分組。由此可得，運用該方案研究的CTR模式，不僅安全性有了很大的提升，加密所消耗的時間理論上也可縮短為串行加密的1/4，運算速率提升明顯。

4 實驗分析

實驗1：在Android平臺下新建測試應用程序，在其中創建一個名為man.db的數據庫，為其新建一張student表，包含user、phone字段，并設置user字段為主鍵。向其中插入十條數據，通過DDMS(Dalvik Debug Monitor Service)導出，用SQLite Expert工具查看。

在不加密的情況下，可以清晰看到各字段信息，查看結果如圖8所示。在使用加密算法的情況下，必須輸入正確口令通過身份認證方可進入數據庫。如果密碼錯誤或直接用工具打開查看，則會有“file is encrypted or is not a database”的錯誤提示。

圖8 未加密時插入的數據信息

Android平臺下數據庫加密系統主要的衡量標準，是加密后該數據庫的性能沒有受到過多影響。表現為加密后占用的存儲空間沒有明顯增加，加密速度足夠快，系統的安全系數較高。下面將分別從這幾個方面對該SQLite加密系統的性能作以分析。

4.1 空間使用分析

本方案在對SQLite加密時，實現了SQLite接口中的加密函數，無疑會增加SQLite數據庫源碼的空間占用率。但在編寫加密函數時，已盡可能地減少加密過程中對空間的占用。主要表現在：

(1) 代碼編寫時，在初始化部分添加了臨時數據的釋放函數。比如，在使用完計數器Tn，自增得到Tn+1后，及時釋放Tn。

(2) 在AES算法并行處理部分，使用了Java多線程機制和線程池。在沒有任務時，線程在線程池中處于休眠狀態，只占據很小的內存空間。本方案中運用線程池管理線程可以防止并發過多，以免內存被過度消耗。

(3) 該SQLite數據庫加密系統使用AES加密，加密前后明文密文的存儲量是一樣的，只是改變了狀態矩陣中的數值。

由上所述，該安全系統在Android平臺下的空間增量可以忽略不計。

4.2 效率分析

實驗2：加解密消耗時間的測試。System.currentTimeMills()函數可獲取系統當前時間，實驗過程中，用此函數分別獲取系統加密前后的時間點，從而計算出時間差即為加密所消耗的時間。插入數據的實驗可得到加密耗費的時間，如圖9所示。查詢數據的實驗可獲取解密耗費的時間，如圖10所示。

圖9 加密消耗時間比較

圖10 解密消耗時間比較

計算分析可知，用本文優化的AES算法不僅沒有降低標準AES加密性能，反而將加密速度平均提高了28.7%，解密速度平均提升了23.5%，運算效率較好。

實驗1和實驗2是在CPU環境為四核四線程的情況下執行的。實驗3將利用本文優化的AES加密算法，通過創建不同數量的線程(實驗以單線程、4線程、8線程、16線程為例)，對該SQLite加密系統的速率變化作以分析，測試結果如圖11所示。

圖11 各線程下加密消耗時間比較

可以看出，對于大小在2 MB以下的短小明文，增加并行線程數(8或16個線程)不會導致AES性能的提升，反而會隨著線程數增多而下降。經分析，這可能是因為并行化過程中，創建大量線程、對明文分組、處理密文時也需要占用資源和時間。實驗表明，使用本文提出的加密系統，4線程比較適合處理短小明文。

4.3 安全性分析

本系統在CTR模式下執行優化的AES算法，每次產生的計數器初值都是不同的，是通過隨機函數產生的16個無符號字符，可以避免因每次產生相同初值造成明文攻擊。

在對AES算法做了優化后，解除了初始密鑰和輪密鑰之間的關系，并對第一輪密鑰做了簡單運算變換，擾亂了攻擊者的思路，提升窮舉攻擊的難度量級。另外，該安全系統通過MD5單向散列函數對用戶口令加密生成初始密鑰，并將口令密文存儲，密鑰安全得到了很好的保障，達到了研究目標。

5 結 語

本文針對Android平臺的硬件特點，對AES-128算法進行了優化，并將其應用在SQLite數據庫中，保護移動端數據隱私。密鑰擴展部分的優化提高了算法的安全性，輪變換部分和CTR模式的并行優化提高了算法的運行效率。實驗結果表明，在該方案下，4線程更適合2 MB以下的短小明文加密。與優化前的標準AES算法相比，優化后SQLite加密速率平均提升28.7%，解密速率平均提升23.5%，同時有效抵抗了攻擊，增加了Android平臺數據隱私保護的安全性，達到了研究目的。