鄧蒞川 周 健 雷靈光 向 繼
1(中國科學(xué)院信息工程研究所信息安全國家重點(diǎn)實(shí)驗(yàn)室 北京 100093)2(中國科學(xué)院大學(xué) 北京 100049)3(中國科學(xué)院數(shù)據(jù)與通信保護(hù)研究教育中心 北京 100093)
基于Android平臺(tái)的文檔保護(hù)方案設(shè)計(jì)與實(shí)現(xiàn)
鄧蒞川1,2,3周 健1,3雷靈光1,3向 繼1,3
1(中國科學(xué)院信息工程研究所信息安全國家重點(diǎn)實(shí)驗(yàn)室 北京 100093)2(中國科學(xué)院大學(xué) 北京 100049)3(中國科學(xué)院數(shù)據(jù)與通信保護(hù)研究教育中心 北京 100093)
近年來,隨著Android平臺(tái)在移動(dòng)設(shè)備上的普及以及企業(yè)移動(dòng)辦公快速發(fā)展的趨勢(shì),Android平臺(tái)上隱私文檔的保護(hù)顯得越發(fā)重要?;谝延形臋n保護(hù)方案的研究,提出一套可供普通應(yīng)用程序使用的輕量級(jí)的移動(dòng)終端文檔保護(hù)方案。該方案使用多重密鑰技術(shù)并結(jié)合密鑰拆分算法,在保證文檔安全性的同時(shí),實(shí)現(xiàn)了對(duì)用戶透明的文檔加解密。該方案還可對(duì)受保護(hù)文檔進(jìn)行實(shí)時(shí)監(jiān)控,以保證其在整個(gè)生命周期內(nèi)的安全性?;谠摲桨冈贏ndroid平臺(tái)上實(shí)現(xiàn)了一個(gè)原型系統(tǒng),并在多個(gè)Android手機(jī)平臺(tái)上進(jìn)行了測(cè)試,實(shí)驗(yàn)結(jié)果驗(yàn)證了該方案的可行性和兼容性。
文檔保護(hù) Android 密鑰拆分 文檔監(jiān)控 移動(dòng)辦公
隨著移動(dòng)通信技術(shù)的發(fā)展,移動(dòng)辦公已成為大勢(shì)所趨。對(duì)于企業(yè)移動(dòng)管控而言,移動(dòng)辦公在提供便捷服務(wù)的同時(shí),也帶來了一些安全隱患。層出不窮的手機(jī)病毒、木馬等使得手機(jī)環(huán)境不安全,文獻(xiàn)[1]表明中國企業(yè)普遍缺乏對(duì)電子文檔的保護(hù)措施;而SearchSecurity網(wǎng)站調(diào)查顯示,30%~40%企業(yè)機(jī)密泄露事件是由電子文檔泄漏造成[2]。Android系統(tǒng)自身的安全性同樣存在不足,如Android手機(jī)中的APP安裝缺乏有效監(jiān)管,黑客可通過將惡意代碼注入正常APP中來竊取用戶私密信息。近年來,通過遠(yuǎn)程控制竊取用戶文檔的事件時(shí)有發(fā)生[6]。
不同于iOS采取整盤加密的機(jī)制,Android文件系統(tǒng)的安全性主要依賴于Linux文件系統(tǒng)基于用戶身份的訪問控制保護(hù)機(jī)制,即不同的用戶組對(duì)文件有不同的讀寫權(quán)限。然而,Linux內(nèi)核存在一些安全漏洞[13],一旦攻擊者利用這些漏洞獲取了系統(tǒng)的Root權(quán)限,則整個(gè)Linux文件系統(tǒng)都會(huì)暴露給惡意代碼,任何存儲(chǔ)位置都是不安全的。隨著普遍增加的企業(yè)文檔共享需求,基于Android平臺(tái)移動(dòng)辦公的數(shù)據(jù)共享安全性也得到越來越多的關(guān)注。因此,如何實(shí)現(xiàn)Android平臺(tái)上隱私文檔的保護(hù)顯得越發(fā)重要。
國際上不少大學(xué)以及研究機(jī)構(gòu)都在電子文檔安全管理研究方面取得了一些成果,如麻省理工學(xué)院(MIT)、IBM研究院等均各自提出了相應(yīng)的理論及系統(tǒng)模型[7]。國內(nèi)的清華大學(xué)、南京大學(xué)等高校學(xué)者也在電子文檔加密、數(shù)據(jù)分發(fā)、密鑰管理及訪問控制等方面做了深入研究[8-9];北京郵電大學(xué)的學(xué)者提出將可信計(jì)算引入到移動(dòng)平臺(tái)中[14],實(shí)現(xiàn)對(duì)文檔的透明加解密,其安全性依賴于一個(gè)關(guān)鍵安全函數(shù),但在對(duì)關(guān)鍵安全模塊的保護(hù)及性能開銷問題上還有待進(jìn)一步研究。
將傳統(tǒng)PC文檔保護(hù)技術(shù)應(yīng)用到移動(dòng)終端,需考慮手機(jī)有限的計(jì)算及存儲(chǔ)能力,以及密鑰在Android平臺(tái)上存儲(chǔ)時(shí)缺乏信任根等問題。手機(jī)文檔保護(hù)需保證文檔存儲(chǔ)、傳輸和使用三個(gè)環(huán)節(jié)的安全性,其中對(duì)文檔數(shù)據(jù)傳輸和文檔載體進(jìn)行管控是使用最為廣泛的措施[3]。目前手機(jī)文檔保護(hù)方案主要有以下幾種:一是不在客戶端存儲(chǔ)文檔,此時(shí)文檔的安全性依賴于客戶端和服務(wù)器端的安全傳輸以及服務(wù)器端的安全存儲(chǔ)[10],但這種方案并不能有效阻止本地惡意程序的攻擊;二是切斷其他數(shù)據(jù)傳輸通道,如禁止用戶在操作文檔時(shí)使用網(wǎng)絡(luò)服務(wù)[3],該方案同樣無法阻止本地惡意程序攻擊;三是改進(jìn)文檔載體,如提供企業(yè)專用的文檔閱讀器來禁止一些不安全操作[12],但閱讀器的定制開發(fā)量大,且兼容性較差,還會(huì)在一定程度上影響用戶的操作習(xí)慣;四是對(duì)文檔進(jìn)行單純加解密[11],在該方案中解密后的新建文件將被放入SD卡,缺乏有效的保護(hù)控制。因此,尋求一種能有效解決上述問題的手機(jī)文檔保護(hù)機(jī)制十分必要。
綜上所述,本文針對(duì)SD卡丟失問題及手機(jī)后臺(tái)惡意程序竊取機(jī)密文件的攻擊,提出了一套移動(dòng)終端文檔保護(hù)機(jī)制;并以SDK的形式進(jìn)行實(shí)現(xiàn),方便第三方應(yīng)用程序調(diào)用,具有良好的兼容性。本方案對(duì)需要保護(hù)的SD卡文檔進(jìn)行多因素密鑰加密保護(hù),且不在本地存儲(chǔ)密鑰,也無需密鑰傳輸操作,因而保證了密鑰的安全性;本方案將對(duì)解密后的臨時(shí)明文文檔進(jìn)行全生命周期監(jiān)控及進(jìn)程間加鎖,確保臨時(shí)明文文檔的安全創(chuàng)建、訪問和銷毀,且僅能由指定程序訪問,還可以按需設(shè)置自定義監(jiān)控策略;方案以SDK形式實(shí)現(xiàn),方便應(yīng)用程序使用,且無需對(duì)閱讀器進(jìn)行任何修改,滿足了文檔共享的需求。實(shí)驗(yàn)測(cè)試表明,本方案開銷較小,且支持對(duì)目前通用文檔格式的保護(hù)。
Android平臺(tái)主要提供以下五種文檔存儲(chǔ)和共享的方法:
? SharedPreference
它是Android提供用于存儲(chǔ)簡單配置信息的機(jī)制,采用Map數(shù)據(jù)結(jié)構(gòu)來存儲(chǔ)數(shù)據(jù),以鍵值的方式存儲(chǔ)。只能在應(yīng)用程序內(nèi)部使用。SharedPreferences以XML格式將數(shù)據(jù)存儲(chǔ)到設(shè)備中,文件系統(tǒng)中的位置在/data/data/
? SQLite數(shù)據(jù)庫
需對(duì)存儲(chǔ)數(shù)據(jù)進(jìn)行較復(fù)雜操作,或數(shù)據(jù)量較大時(shí),需要采用SQLite來更高效管理數(shù)據(jù),它是一種獨(dú)立的無需服務(wù)進(jìn)程,支持事務(wù)處理,可以使用SQL語言的數(shù)據(jù)庫。
? ContentProvider
即應(yīng)用程序間共享數(shù)據(jù)的統(tǒng)一接口,只有擁有相應(yīng)權(quán)限才可獲得Content provider,并查詢它們包含的數(shù)據(jù)。
? 文件存儲(chǔ)(內(nèi)部存儲(chǔ))
系統(tǒng)提供 openFileInput()和openFileOutput()方法來讀取設(shè)備上的文件,且只能在應(yīng)用程序內(nèi)部訪問。文件系統(tǒng)中存儲(chǔ)路徑一般為:/data/data/Package Name/files。文件存儲(chǔ)有四種操作模式:MODE_PRIVATE、MODE_ APPEND、MODE_WORLD_READABLE、MODE_WORLD_WRITEABLE
? SD卡文件(外部存儲(chǔ))
Android訪問外部存儲(chǔ)即SD卡文件需要“WRITE_EXTERNAL_STORAGE”權(quán)限,并需在使用前檢查外部存儲(chǔ)的可用性。
以上五種文檔存儲(chǔ)和共享方式中,內(nèi)部存儲(chǔ)安全性較高,但共享性較低;外部存儲(chǔ)只需有相應(yīng)權(quán)限即可訪問,相對(duì)安全性低,但共享性更高。為兼顧文檔安全性和共享性需求,本文將重點(diǎn)關(guān)注如何提高SD卡文件存儲(chǔ)的安全性。
由于智能移動(dòng)終端有文檔保護(hù)和文檔共享的雙重需求,而現(xiàn)有的移動(dòng)終端文檔保護(hù)方案很少能同時(shí)兼顧這兩點(diǎn)需求。因此,本文提出一套文檔保護(hù)方案,以期實(shí)現(xiàn)安全的文檔共享。本設(shè)計(jì)方案架構(gòu)基于Android平臺(tái),并以SDK形式實(shí)現(xiàn),方便集成到第三方應(yīng)用程序中,僅需用戶在程序初始化時(shí)提供用于身份認(rèn)證和透明加解密的PIN碼,具有很好的普適性。本方案可以提供集中管理文檔的功能,適用于企業(yè)移動(dòng)辦公。
2.1 攻擊模型
對(duì)于存儲(chǔ)在SD卡上的文檔,本文考慮以下幾種攻擊:
? 攻擊者通過竊取SD卡來獲取SD卡上文件;
? 惡意程序后臺(tái)訪問SD卡文件;
? 在手機(jī)root的情況下,惡意程序后臺(tái)訪問應(yīng)用本地存儲(chǔ)。
本方案針對(duì)上述攻擊提出相應(yīng)的防護(hù)策略,來自內(nèi)部的信息泄露不在本文討論范圍。
2.2 保護(hù)模型
針對(duì)2.1節(jié)所述攻擊模型,本文提出保護(hù)模型如圖1所示。
圖1 保護(hù)模型圖
受保護(hù)文檔在SD卡上加密存儲(chǔ),惡意程序后臺(tái)訪問SD卡文件時(shí),由于沒有密鑰信息故無法破解密文。密文文檔當(dāng)且僅當(dāng)用戶通過APP進(jìn)行顯式請(qǐng)求時(shí),才會(huì)被解密,且密鑰只部分存儲(chǔ)在本地受保護(hù)區(qū)域,故敵手即使通過root拿到部分密鑰,也無法完成解密工作。
惡意程序在自己的dalvik虛擬空間內(nèi),無法訪問第三方APP的虛擬空間,故也只可獲取SD卡上的加密文檔。第三方APP接收到打開文檔的請(qǐng)求時(shí),由用戶選擇閱讀器,進(jìn)而申請(qǐng)閱讀文檔,文檔將在第三方APP的虛擬空間內(nèi)被解密放到臨時(shí)空間中,由文檔監(jiān)控模塊監(jiān)控保護(hù);閱讀器操作完成后即刻銷毀明文并回收臨時(shí)空間,該過程中惡意程序無法獲取文檔明文。
該保護(hù)方案相當(dāng)于為APP提供了一塊私密且安全的“保險(xiǎn)箱”,對(duì)文檔的加解密以及對(duì)明文空間的監(jiān)控都與APP在同一個(gè)dalvik虛擬機(jī)[4]里。
(1) 密鑰機(jī)制
文檔安全性很大程度依賴于密鑰保護(hù),因此,需設(shè)計(jì)一套完整、安全的密鑰生成、存儲(chǔ)、使用和管理機(jī)制。
本方案采用密鑰拆分和多重密鑰思想,主要涉及三種密鑰:用于加密文檔的密鑰SessionKey、用于加密SessionKey的主密鑰MasterKey、用于加密MasterKey的根密鑰KeyKey(只在程序啟動(dòng)時(shí)動(dòng)態(tài)獲取);以及用于身份認(rèn)證的PIN碼。上述這些敏感數(shù)據(jù)都不在本地存儲(chǔ),也無需傳輸,故安全性得到了保證。
由于本方案的實(shí)現(xiàn)均在客戶端進(jìn)行,故采用對(duì)稱加密算法。
為了提高移動(dòng)辦公的效率,本方案考慮把用于加解密文檔的密鑰暫存于手機(jī)客戶端,并引入MasterKey來保護(hù)文檔密鑰SessionKey,以杜絕密鑰泄露的風(fēng)險(xiǎn);本方案中客戶端僅維護(hù)一個(gè)映射表:文檔唯一識(shí)別號(hào)和MasterKey [SessionKey] 加密后字符串一一對(duì)應(yīng)。
符號(hào)表示如下: PIN為用于用戶驗(yàn)證的字符串;RNG為根隨機(jī)數(shù),用于生成保護(hù)主密鑰的密鑰,由固定密鑰加密存儲(chǔ)于設(shè)備;INFO為設(shè)備硬件信息,將密鑰與設(shè)備綁定,確保更換設(shè)備時(shí)當(dāng)前密鑰失效,設(shè)備信息不存儲(chǔ),直接從系統(tǒng)中提??;random為每個(gè)文檔對(duì)應(yīng)的隨機(jī)數(shù),不存儲(chǔ),只用于第一次加密時(shí)生成SessionKey;SK表示加密文檔的密鑰SessionKey(SK’表示加密后);MK表示加密SessionKey的密鑰MasterKey(MK’表示加密后);KK表示加密MasterKey的根密鑰KeyKey;m表示文檔明文,s表示文檔密文;E(*)表示對(duì)稱加密過程,D(*)表示對(duì)稱解密過程;P(*)為既定密鑰生成算法。
則 KK生成:KK = P( PIN + RNG + INFO)
主密鑰MK加密:MK’ = E(KK , MK)
主密鑰MK解密:MK = D(MK’ , KK)
SK生成:SK = P( PIN + random + INFO)
文檔密鑰SK加密:SK’ = E(SK , MK)
文檔密鑰SK解密:SK = D(SK’ , MK)
文檔加密:s = E(m , SK)
文檔解密:m = D(s , SK)
(2) 文檔監(jiān)控
文檔保護(hù)方案一般涉及以下兩種情況:一種是文檔解密后使用指定閱讀器打開,從而保證其安全性,但這種方法兼容性和擴(kuò)展性較差;另一種是將明文緩存,而緩存的明文易受攻擊,安全性較低。
本文方案由監(jiān)控模塊監(jiān)控針對(duì)文檔的各項(xiàng)操作。方案中在操作文檔的請(qǐng)求通過驗(yàn)證并由用戶手動(dòng)選擇第三方閱讀器后,才執(zhí)行解密操作;文檔明文被放在監(jiān)控模塊新建的臨時(shí)空間中,并通過設(shè)置該閱讀器打開文檔時(shí)的參數(shù),以確保其他閱讀器對(duì)其無法訪問;閱讀器打開文檔耗時(shí)很短,臨時(shí)明文只存在很短的時(shí)間,故降低了本方案被攻擊的可能性;在閱讀器退出操作后,臨時(shí)文件空間被程序自動(dòng)回收且文檔明文被即刻銷毀。
2.3 模塊設(shè)計(jì)
本方案以SDK形式實(shí)現(xiàn),第三方APP可自行調(diào)用接口函數(shù)。SDK主要由以下幾個(gè)模塊組成:
? 密鑰管理模塊:主要負(fù)責(zé)生成密鑰,驗(yàn)證用戶PIN碼;
? 數(shù)據(jù)加解密模塊:主要負(fù)責(zé)對(duì)文檔加解密,及對(duì)隨機(jī)數(shù)的加解密;
? 文檔監(jiān)控模塊:提供對(duì)文檔整個(gè)生命周期的監(jiān)控保護(hù),解密后臨時(shí)明文存于新建臨時(shí)空間,并對(duì)臨時(shí)明文的操作進(jìn)行實(shí)時(shí)監(jiān)控,判斷閱讀器關(guān)閉文檔后銷毀明文。
模塊如圖2所示。
圖2 文檔保護(hù)方案模塊設(shè)計(jì)圖
由于Android4.1及之后的4.2、4.3統(tǒng)稱為Android Jelly Bean,包括后續(xù)的Android4.4是目前Android市場(chǎng)份額占有最大的系統(tǒng)版本。本節(jié)給出了一個(gè)基于Android平臺(tái)4.2及以上版本的手機(jī)文檔保護(hù)方案實(shí)現(xiàn)原型,分為初始化、加密和解密進(jìn)行流程分析,最后進(jìn)行相應(yīng)的技術(shù)和性能分析。
3.1 實(shí)現(xiàn)流程
(1) 初始化
初始化流程如圖3所示。
圖3 文檔保護(hù)方案初始化流程圖
? 生成設(shè)備硬件信息INFO;
? 對(duì)指定信息INFO用指定算法進(jìn)行一次加密,用于后續(xù)驗(yàn)證PIN碼正確性;
? 生成一個(gè)“根隨機(jī)數(shù)”(RNG),存于私有空間;
? [PIN+RNG+INFO]用指定算法生成根密鑰KeyKey;
? 生成任意字段,即與保護(hù)密鑰無關(guān)的信息,作為主密鑰MasterKey;
? KeyKey[ MasterKey ]加密后存儲(chǔ)于私有空間。
初始化過程僅在程序啟動(dòng)時(shí)執(zhí)行,其余時(shí)候可以直接從內(nèi)存讀取MasterKey。
(2) 加密
加密流程如圖4所示。
圖4 文檔保護(hù)方案加密流程圖
用戶輸入PIN碼,解密預(yù)存儲(chǔ)的PIN[INFO]進(jìn)行判斷,解密成功則通過驗(yàn)證,程序獲取MasterKey;身份認(rèn)證失敗則提示用戶重新輸入PIN碼,連續(xù)錯(cuò)誤五次即被鎖定,不能選擇文檔。用戶通過驗(yàn)證后,在不退出程序的前提下可多次選擇文檔進(jìn)行加密。
選定文檔后,后臺(tái)生成三個(gè)因素的字符串,即設(shè)備硬件信息、文檔對(duì)應(yīng)隨機(jī)數(shù)、PIN碼,按指定算法生成密鑰SessionKey,用SessionKey加密文檔。
加密成功則將MasterKey [ SessionKey ]加密保護(hù)后存儲(chǔ)到程序私有空間;加密失敗則告知用戶,并可重新選擇文檔進(jìn)行加密。
(3) 解密
解密流程如圖5所示。
圖5 文檔保護(hù)方案解密流程圖
用戶選擇想閱讀的文檔,程序需用戶輸入PIN碼,程序按(2)所述方法驗(yàn)證PIN碼。
正確則進(jìn)而判斷內(nèi)存是否有MasterKey,有則用MasterKey解密得到SessionKey對(duì)文檔進(jìn)行解密;
內(nèi)存沒有MasterKey,即程序啟動(dòng)初始化,后臺(tái)獲取三部分拆分信息,動(dòng)態(tài)生成根密鑰KeyKey,解密得到MasterKey。用MasterKey獲取文檔SessionKey進(jìn)而對(duì)文檔解密。
解密失敗則告知用戶,重新選擇文檔;解密成功則進(jìn)入文檔監(jiān)控周期。文檔監(jiān)控周期處理流程如下:
① 文檔創(chuàng)建:監(jiān)控模塊動(dòng)態(tài)創(chuàng)建臨時(shí)空間,將密文文檔解密后暫時(shí)存放;
② 文檔打開:通過獲取sun.nio.FileChannel對(duì)象實(shí)現(xiàn)進(jìn)程加鎖,其他程序進(jìn)程無法訪問臨時(shí)明文空間,從而其他的第三方無法獲取到明文信息;
③ 文檔關(guān)閉:閱讀器對(duì)文檔的閱讀和操作都是在自己的dalvik虛擬空間中進(jìn)行的,其他APP不能訪問該虛擬空間也不能獲知其是否操作完成,本方案利用Android系統(tǒng)提供的對(duì)SD卡監(jiān)聽機(jī)制,周期性地監(jiān)聽臨時(shí)明文空間下對(duì)文檔的操作,一旦發(fā)現(xiàn)臨時(shí)明文文件在預(yù)置時(shí)間長度內(nèi)處于空閑狀態(tài),即刻銷毀明文。
考慮到大文檔直接進(jìn)行加解密處理可能效率很低,甚至可能出現(xiàn)內(nèi)存溢出錯(cuò)誤。本方案的文檔加解密使用分塊處理,則對(duì)于大小文件的處理在內(nèi)存消耗上差異不大, 3.2節(jié)的實(shí)驗(yàn)分析亦驗(yàn)證了這一點(diǎn)。
3.2 分析及實(shí)驗(yàn)
(1) 性能分析
? 安全性
本方案可以抵抗以下幾種安全威脅:
a) SD卡丟失,由于密鑰需設(shè)備硬件號(hào)生成,SD卡丟失無法獲取密鑰。
b) 惡意程序后臺(tái)訪問SD卡文件,沒有用戶PIN碼;即使竊取得到用戶PIN碼,亦無法訪問內(nèi)部存儲(chǔ),因而無法獲取完整密鑰。
c) 惡意程序通過root獲取內(nèi)部存儲(chǔ)的部分密鑰,也無法獲取完整密鑰。
? 可用性
a) 加解密透明,無需改變用戶使用習(xí)慣。
b) 本方案采用的算法對(duì)文檔進(jìn)行分塊處理,文檔加解密過程性能開銷較小。
c) 無需定制閱讀器,對(duì)通用閱讀器均能支持。
? 算法性能分析
本文先用普通對(duì)稱加密算法(AES)對(duì)不同大小的文件進(jìn)行加解密,實(shí)驗(yàn)結(jié)果表明加解密開銷與文件大小呈正相關(guān)關(guān)系,且大文件(如大于30 MB)的加解密造成時(shí)間開銷過大,會(huì)對(duì)用戶操作造成不良影響。假設(shè)文件大小為N,此時(shí)加解密算法復(fù)雜度為:O(N)。
在對(duì)大文件的處理方面,本方案做了如下優(yōu)化,對(duì)文檔進(jìn)行預(yù)處理操作,分為大小為[1024×1024]位的塊,再調(diào)用對(duì)稱加密算法進(jìn)行加解密,從而加解密的性能開銷只與分塊大小有關(guān)。下面將通過實(shí)驗(yàn)進(jìn)行分析驗(yàn)證。
(2) 實(shí)驗(yàn)分析
本文針對(duì)方案的兼容性和性能開銷進(jìn)行了實(shí)驗(yàn)。兼容性即本方案支持通用的幾種Android平臺(tái)閱讀器可用,支持通用的幾種文檔格式可加解密;性能開銷即受本方案保護(hù)的APP對(duì)設(shè)備內(nèi)存開銷較小。
表1為普通對(duì)稱加密算法、分塊優(yōu)化后的算法,以及不同分塊大小造成的性能開銷。
表1 分塊優(yōu)化文檔保護(hù)方案性能開銷
續(xù)表1
表1中0、1、2、3、4分別代表:未分塊、分塊大小為[2048×2048]、[1024×1024]、[512×512]、[256×256]。
表1內(nèi)存和電池功耗均為本方案原型的開銷,時(shí)間延遲為加密、存儲(chǔ)、解密,及閱讀器解析打開文件的總時(shí)間,其中文檔中存在閱讀器不能識(shí)別的內(nèi)容,或媒體文件過多,會(huì)增加解析時(shí)間,引起更多的時(shí)間延遲;從時(shí)間延遲看出未分塊的加密算法在處理大文件時(shí)延遲嚴(yán)重,而本方案對(duì)文檔進(jìn)行分塊處理,從實(shí)驗(yàn)數(shù)據(jù)可以看出能夠一定程度上減少時(shí)間延遲,且下一步還可加入多線程并行處理多個(gè)分塊,將進(jìn)一步優(yōu)化算法性能,將時(shí)間復(fù)雜度降低至O(n),n為分塊大小;通用文檔格式均能正常加解密,且不同格式文檔加解密性能開銷差異不大,打開文檔的性能開銷與閱讀器處理識(shí)別不同格式文檔有關(guān)。
表2為本方案原型在不同手機(jī)上對(duì)小文件(小于1MB)和大文件(大于30MB)進(jìn)行加解密的性能開銷。
表2 文檔保護(hù)方案在不同手機(jī)平臺(tái)上性能開銷
表2中電池功耗為文檔加解密時(shí)的手機(jī)當(dāng)前功耗,可以看出在不同手機(jī)平臺(tái)上加解密功耗均小于1W;手機(jī)在應(yīng)用程序運(yùn)行時(shí)的內(nèi)存用量普遍保持在20MB以下,且由于分塊技術(shù)的使用,在對(duì)大小文檔的加解密時(shí)內(nèi)存用量差異不大;CPU占用率普遍不超過5%。以上實(shí)驗(yàn)在通用第三方文檔閱讀器,即WPSOffice、PolarisOffice、QuickOffice、ThinkFreeOffice及金軟Office上均進(jìn)行了實(shí)驗(yàn),均能正常使用本原型系統(tǒng)。實(shí)驗(yàn)表明本方案原型系統(tǒng)整體性能開銷較小,且對(duì)大文件和小文件的加解密處理開銷差異不大,故本方案可行。
手機(jī)文檔安全對(duì)企業(yè)移動(dòng)管理至關(guān)重要,僅靠現(xiàn)有的Android安全機(jī)制難以滿足企業(yè)需求。本文設(shè)計(jì)開發(fā)了一套基于Android的輕量級(jí)手機(jī)文檔保護(hù)方案,提供一套能滿足企業(yè)移動(dòng)辦公需求的密鑰管理體系,實(shí)現(xiàn)了文檔的透明加解密功能,并兼容現(xiàn)有通用第三方閱讀器方便通用文檔的讀取。本方案中的文檔操作全程受后臺(tái)監(jiān)控,一旦操作完畢臨時(shí)明文空間即被收回且文檔明文被即刻銷毀。經(jīng)測(cè)試,本文實(shí)現(xiàn)的原型系統(tǒng)開銷較小,具有較好的可用性和兼容性。在本方案的具體實(shí)現(xiàn)中,分組加密為串行處理,因此大文件可能帶來一定的可感知延遲,實(shí)際應(yīng)用中采用并行處理,將進(jìn)一步降低時(shí)間復(fù)雜度,減少可感知延遲。
[1] 企業(yè)電子文檔的安全調(diào)查報(bào)告[R/OL].http://wenku.baidu.com/link?url=ga6q6-NGJdMPhIUwJTNPm9OezAUn49t-kO3dtYG3S_otCWnQzMYi3BAxhtWBBt9LTxhxGzeuqB_zi2asjYmzTRS1_VNn0u2mREkt9GVApjO.
[2] 百度百科.電子文檔保護(hù)[DB/OL].http://baike.baidu.com/view/1743385.htm.
[3] 施超.信息安全的重要性與文檔加密技術(shù)在企業(yè)中的應(yīng)用[J].中國管理信息化,2015,18(6):203.
[4]Wikipedia.Dalvik(Software)[DB/OL].http://en.wikipedia.org/wiki/Dalvik_(software).
[5] Android系統(tǒng)各版本市場(chǎng)份額進(jìn)化圖[OL].http://www.199it.com/archives/311622.html.
[6] 巧艷.Android遠(yuǎn)程控制惡意軟件興起 可竊取用戶信息[OL].http://www.newhua.com/2013/0718/224074.shtml.
[7] Hennessy S D,Lauer G D,Zunic N,et al.Data-centric security:Intergrating data privacy and data security[J].IBM Journal of Research and Development,2009,53(2):208-224.
[8] 鄭磊,馬兆豐,顧明.基于文件系統(tǒng)過濾驅(qū)動(dòng)的安全增強(qiáng)型加密系統(tǒng)技術(shù)研究[J].小型微型計(jì)算機(jī)系統(tǒng),2007,28(7):1181-1184.
[9] 劉岸,吳琨,仲海駿,等.基于策略機(jī)制的分布式文件保護(hù)系統(tǒng)PFICS[J].計(jì)算機(jī)工程,2004,30(18):119-121.
[10] 廉喆.手機(jī)文檔保護(hù)系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[D].北京郵電大學(xué),2010.
[11] 周巧扣,倪紅軍.基于Android的文件加密系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[J].計(jì)算機(jī)光盤軟件與應(yīng)用,2013(16):245-246,248.
[12] 朱筱赟,胡愛群,邢月秀,等.基于Android平臺(tái)的移動(dòng)辦公安全方案綜述[J].信息網(wǎng)絡(luò)安全,2015(1):76-83.
[13] CVE 2009-1185[OL].https://launchpad.net/bugs/cve/2009-1185.
[14] Yu X,Wen Q,Yan T.A novel solution to document protection on mobile platform[M]//Future Wireless Networks and Information Systems.Springer,2012:447-455.
DESIGN AND IMPLEMENTATION OF DOCUMENT PROTECTION SCHEME BASED ON ANDROID PLATFORM
Deng Lichuan1,2,3Zhou Jian1,3Lei Lingguang1,3Xiang Ji1,3
1(StateKeyLaboratoryofInformationSecurity,InstituteofInformationEngineering,ChineseAcademyofSciences,Beijing100093,China)2(UniversityofChineseAcademyofSciences,Beijing100049,China)3(DataAssuranceandCommunicationSecurityResearchCenter,ChineseAcademyofSciences,Beijing100093,China)
As mobile devices of Android are becoming more and more prevalent among enterprises as well as the individuals, the protection of private documents on Android platform is getting more and more important. On the basis of existing researches, a lightweight mobile document protection scheme for general applications is proposed, which used the technology of key splitting and multiple-key system. The process of encryption and decryption is transparent to the user without any perceptible delay. The scheme provided real-time monitoring to protect the confidentiality of documents during the whole lifecycle. Moreover, a prototype system on Android platform has been implemented based on the scheme, and it had been tested on several Android platforms. Experiment results show that the scheme is practical and compatible with the mainstream Android platforms.
Document protection Android Key split Document monitor Mobile office
2015-12-14。國家高技術(shù)研究發(fā)展計(jì)劃項(xiàng)目(2013AA01A214)。鄧蒞川,碩士生,主研領(lǐng)域:移動(dòng)終端安全。周健,助理研究員。雷靈光,助理研究員。向繼,高級(jí)工程師。
TP3
A
10.3969/j.issn.1000-386x.2017.02.057