基于Android平臺的SQLite數(shù)據(jù)庫加密研究

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

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

0 引 言

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

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

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

1 相關(guān)技術(shù)

1.1 SQLite加密方式

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

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

圖1 sqlite3CodecAttach()函數(shù)流程圖

口令的來源有兩種，用戶創(chuàng)建賬號時自行設(shè)置的密鑰和主數(shù)據(jù)庫的密鑰。系統(tǒng)確定密鑰來源后，調(diào)用相應(yīng)函數(shù)獲取口令，實現(xiàn)sqlite3CodecAttach()函數(shù)，繼而在sqlite3_key()中調(diào)用。

1.2 加密算法

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

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

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

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

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

2 SQLite數(shù)據(jù)庫加密設(shè)計

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

圖2 SQLite數(shù)據(jù)庫安全模型

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

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

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

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

用戶存取數(shù)據(jù)時，SQLite加解密的整體結(jié)構(gòu)如圖3所示。

圖3 SQLite加解密過程

系統(tǒng)首先判斷用戶是否首次登錄；若是，用戶創(chuàng)建口令，系統(tǒng)口令經(jīng)過MD5散列轉(zhuǎn)化為固定長度的輸出，作為優(yōu)化AES加解密算法的初始密鑰K，并存儲在SQLite中；若不是，繼而判斷輸入口令是否正確，正確則進(jìn)入系統(tǒng)，執(zhí)行相應(yīng)加解密操作。

3 AES算法的改進(jìn)

3.1 密鑰擴(kuò)展算法的改進(jìn)

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

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

圖4 改進(jìn)的密鑰擴(kuò)展算法過程

性能分析：

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

(1)

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

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

3.2 輪變換優(yōu)化

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

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

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

圖5 改進(jìn)的輪變換過程

性能分析：

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

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

(2)

改進(jìn)后的輪變換消耗時間為：

(3)

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

3.3 CTR模式下的并行運算

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

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

圖6 CTR分組模式加密流程

圖7 CTR分組模式解密流程

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

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

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

4 實驗分析

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

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

圖8 未加密時插入的數(shù)據(jù)信息

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

4.1 空間使用分析

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

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

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

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

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

4.2 效率分析

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

圖9 加密消耗時間比較

圖10 解密消耗時間比較

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

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

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

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

4.3 安全性分析

本系統(tǒng)在CTR模式下執(zhí)行優(yōu)化的AES算法，每次產(chǎn)生的計數(shù)器初值都是不同的，是通過隨機函數(shù)產(chǎn)生的16個無符號字符，可以避免因每次產(chǎn)生相同初值造成明文攻擊。

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

5 結(jié) 語

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