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

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

0 引 言

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

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

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

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

1.1 SQLite加密方式

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

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

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

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

1.2 加密算法

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

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

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

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

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

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

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

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

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

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

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

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

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

圖3 SQLite加解密過程

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

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

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

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

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

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

性能分析：

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

(1)

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

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

3.2 輪變換優(yōu)化

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

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

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

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

性能分析：

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

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

(2)

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

(3)

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

3.3 CTR模式下的并行運(yùn)算

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

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

圖6 CTR分組模式加密流程

圖7 CTR分組模式解密流程

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

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

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

4 實(shí)驗(yàn)分析

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

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

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

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

4.1 空間使用分析

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

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

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

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

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

4.2 效率分析

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

圖9 加密消耗時(shí)間比較

圖10 解密消耗時(shí)間比較

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

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

圖11 各線程下加密消耗時(shí)間比較

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

4.3 安全性分析

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

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

5 結(jié) 語

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