李 凌,劉子豪

1(河海大學(xué) 計(jì)算機(jī)與信息學(xué)院,南京 211100)

2(江蘇科技大學(xué) 計(jì)算機(jī)學(xué)院,鎮(zhèn)江 212003)

隨著移動(dòng)互聯(lián)網(wǎng)技術(shù)的興起,QQ、微信、微博等一系列移動(dòng)互聯(lián)網(wǎng)社交平臺(tái)成為年輕人的新寵,越來(lái)越受人們的喜愛.在日常的學(xué)習(xí)、生活乃至工作中,我們都可以方便利用這些平臺(tái)完成和他人的信息交流,大大節(jié)約了交流成本.社交軟件中消息的通信主要由社交軟件的服務(wù)器先進(jìn)行保存然后轉(zhuǎn)發(fā)給目標(biāo)用戶,這不可避免在交流的過(guò)程中會(huì)在軟件的服務(wù)器上留下長(zhǎng)期的數(shù)據(jù)副本,一旦服務(wù)器產(chǎn)生漏洞將有可能導(dǎo)致用戶大量歷史數(shù)據(jù)副本的泄露.本文根據(jù)目前對(duì)移動(dòng)端數(shù)據(jù)安全自毀的需要,充分發(fā)揮微信現(xiàn)有用戶量大,推廣方便的特點(diǎn),以一種基于網(wǎng)絡(luò)的數(shù)據(jù)自毀方法[1]作為服務(wù)器端的數(shù)據(jù)安全自毀基礎(chǔ)方案進(jìn)行改進(jìn),使用嵌入在微信公眾平臺(tái)中的網(wǎng)頁(yè)發(fā)送原文件,利用客戶端以及服務(wù)期端的通信安全由TLS協(xié)議保證并結(jié)合基于微信的第三方網(wǎng)頁(yè)授權(quán)OAuth2.0[2]機(jī)制驗(yàn)證用戶的身份構(gòu)建出可以為移動(dòng)端用戶提供基于微信的數(shù)據(jù)安全自毀的服務(wù)平臺(tái).

1 微信公眾號(hào)及相關(guān)技術(shù)簡(jiǎn)介

微信是騰訊公司于 2011年 1 月 21 日推出的一款手機(jī)應(yīng)用.微信用戶可以通過(guò)軟件與好友分享文字與圖片,并且支持語(yǔ)音、視頻等多功能的服務(wù).微信公眾平臺(tái)是騰訊公司基于微信基礎(chǔ)平臺(tái)上新增的模塊,每個(gè)QQ賬號(hào)都可以打造屬于自己的微信公眾號(hào),微信公眾平臺(tái)可以為特定群體提供自定義的服務(wù).隨著微信與手機(jī)號(hào)的綁定,各種各樣基于微信身份的互聯(lián)網(wǎng)應(yīng)用服務(wù)隨之產(chǎn)生.為了有效的獲取到微信用戶的基本信息,微信推出了第三方網(wǎng)頁(yè)授權(quán)OAuth2.0 機(jī)制.

微信網(wǎng)頁(yè)授權(quán)OAuth2.0 機(jī)制是用戶在微信中訪問(wèn)第三方網(wǎng)頁(yè)時(shí),公眾號(hào)通過(guò)網(wǎng)頁(yè)授權(quán)取得用戶基本信息,進(jìn)而實(shí)現(xiàn)業(yè)務(wù)邏輯的機(jī)制.第三方網(wǎng)頁(yè)通過(guò)該機(jī)制獲取到用戶信息的前提有 2個(gè).第一,授權(quán)的第三方頁(yè)面需提前在微信開發(fā)者中心進(jìn)行域名配置.第二,被獲取信息的用戶必須在 48 小時(shí)內(nèi)和公眾號(hào)有過(guò)最基本的數(shù)據(jù)交互,并且用戶處于關(guān)注該公眾號(hào)的狀態(tài).當(dāng)用戶點(diǎn)擊處理過(guò)的第三方網(wǎng)頁(yè)鏈接時(shí),會(huì)首先自動(dòng)跳轉(zhuǎn)到微信授權(quán)中心確認(rèn)該鏈接是否是在指定的微信默認(rèn)游覽器中打開以及鏈接的域名是否提前在微信的開發(fā)者中心配置過(guò).若通過(guò)微信授權(quán)中心的驗(yàn)證,則返回當(dāng)前用戶OpenID所對(duì)應(yīng)的一次性code,作為參數(shù)傳入重定向的業(yè)務(wù)頁(yè)面.在業(yè)務(wù)頁(yè)面中,服務(wù)商使用一次性code可以換取到對(duì)應(yīng)的用戶包括OpenID在內(nèi)基本信息,確保用戶身份的真實(shí)有效.

2 相關(guān)工作

微信具有用戶量大,服務(wù)平臺(tái)使用方便,推廣迅速的特點(diǎn).目前,社交軟件中帶有敏感數(shù)據(jù)的數(shù)據(jù)的泄露主要有以下兩個(gè)主要途徑:1、帶有敏感信息的數(shù)據(jù)在傳輸中泄露.2、存儲(chǔ)在服務(wù)器數(shù)據(jù)庫(kù)上的數(shù)據(jù)副本被竊取.由于社交軟件普遍使用HTTP協(xié)議進(jìn)行通信,雖然對(duì)通信的消息內(nèi)容部分進(jìn)行過(guò)一定的加密處理,但其通信安全完全依賴于加密密鑰的安全,一旦密鑰泄露將導(dǎo)致通信安全的下降.并且在傳遞的過(guò)程中,數(shù)據(jù)都是以副本的形式進(jìn)行傳遞,其不可避免的會(huì)在服務(wù)器上留下數(shù)據(jù)的副本.在服務(wù)器內(nèi),為方便調(diào)用用戶的數(shù)據(jù),一般都會(huì)設(shè)置訪問(wèn)權(quán)限,然而從烏云網(wǎng)上可以發(fā)現(xiàn)由于服務(wù)器漏洞的頻發(fā)以及部分業(yè)務(wù)邏輯設(shè)計(jì)的不合理,攻擊者常?？梢苑欠ǖ墨@取訪問(wèn)權(quán)限或者繞過(guò)訪問(wèn)權(quán)限,獲取到大量的用戶歷史數(shù)據(jù)副本.

微信自發(fā)布運(yùn)行至今,安全性問(wèn)題時(shí)有發(fā)生.2014年發(fā)生了所謂的視頻泄露事件,后騰訊官方證實(shí)并非微信本身存在漏洞,但專家表示在微信內(nèi)容分享機(jī)制中確有考慮不周之處.2016年8月,采用了X5內(nèi)核的微信被證實(shí)存在高危安全漏洞,該技術(shù)漏洞將允許黑客取得微信的完全控制權(quán),獲取包括微信隱私、聊天記錄、微信錢包等在內(nèi)的信息[3].誰(shuí)也無(wú)法保證今后不會(huì)再次出現(xiàn)類似的安全性問(wèn)題.聊天記錄,賬單信息這些數(shù)據(jù)是否需要持久化存儲(chǔ)? 某些數(shù)據(jù)用戶因?yàn)殡[私不希望持久記錄且不被任何人得知,希望實(shí)現(xiàn)真正的“閱后即焚”.但是這些記錄在“刪除”后仍然可以通過(guò)技術(shù)手段還原,因此數(shù)據(jù)的自毀就顯得很有必要.

本文為解決上述存在的問(wèn)題,以一種基于網(wǎng)絡(luò)的數(shù)據(jù)自毀方法作為服務(wù)器端的數(shù)據(jù)自毀基礎(chǔ)方案進(jìn)行改進(jìn),利用TLS協(xié)議保證通信傳輸中的數(shù)據(jù)安全,結(jié)合微信的第三方網(wǎng)頁(yè)授權(quán)OAuth2.0機(jī)制完成數(shù)據(jù)安全自毀服務(wù)平臺(tái)的構(gòu)建.自毀服務(wù)器以公眾號(hào)為媒介,位于用戶端和微信服務(wù)端之間.用戶通過(guò)微信服務(wù)器提供的身份驗(yàn)證功能登錄公眾號(hào),利用公眾號(hào)為媒介傳遞數(shù)據(jù),自毀服務(wù)器為公眾號(hào)提供加密解密以及自毀等功能.

3 基于微信的數(shù)據(jù)安全自毀服務(wù)平臺(tái)設(shè)計(jì)

3.1 系統(tǒng)信息流轉(zhuǎn)過(guò)程

基于微信的數(shù)據(jù)安全自毀服務(wù)平臺(tái)的數(shù)據(jù)流轉(zhuǎn)過(guò)程如圖1 所示.發(fā)送方用戶通過(guò)微信公眾平臺(tái)的自定義菜單打開數(shù)據(jù)上傳頁(yè)面,按照規(guī)定填寫好所需要的數(shù)據(jù).將所有的相關(guān)數(shù)據(jù)直接發(fā)送給數(shù)據(jù)安全自毀服務(wù)器,傳輸過(guò)程的安全由TLS協(xié)議保障.數(shù)據(jù)安全自毀服務(wù)器利用接受到的數(shù)據(jù)對(duì)原數(shù)據(jù)進(jìn)行加密分片處理,返回的SDD代理鏈接[4]包裝成微信規(guī)定的圖文消息的XML格式發(fā)送給微信服務(wù)器,如圖2.由微信服務(wù)器通過(guò)客服接口直接轉(zhuǎn)發(fā)給接收方用戶.接收方用戶通過(guò)點(diǎn)擊接收到的圖文消息的方式完成身份的驗(yàn)證后,直接從數(shù)據(jù)安全自毀服務(wù)器上獲取到原數(shù)據(jù).圖文消息封裝格式如表1.

圖1 系統(tǒng)信息流程表

圖2 XML文件

表1 參數(shù)描述

3.2 數(shù)據(jù)加密模型

本文利用珠鏈模型(Bead Strand Model),將數(shù)據(jù)分為兩個(gè)部分,珠(Beads)和鏈(Strand).如圖3所示,珠被一根特定的鏈所連接.該模型與單純的鏈表不同,它是一個(gè)面向流數(shù)據(jù)的存儲(chǔ)結(jié)構(gòu),不僅僅提供了數(shù)據(jù)持久化,還涵蓋可眾多的數(shù)據(jù)類型.

圖3 珠鏈模型結(jié)構(gòu)

利用該模型對(duì)數(shù)據(jù)流進(jìn)行加密,并存儲(chǔ)進(jìn)自毀服務(wù)器數(shù)據(jù)庫(kù)中.其過(guò)程分為4個(gè)步驟:

第一步,產(chǎn)生一個(gè)隨機(jī)值作為key,記作RandomKey,之后將輸入的數(shù)據(jù)和RandomKey結(jié)合一起進(jìn)行加密,記作CipherData.通過(guò)使用對(duì)稱加密算法,獲得加密數(shù)據(jù).本文具體使用了AES加密算法[5],該算法使安全性和有效性得到了平衡.

第二步,計(jì)算CipherData的哈希值,得到CipherHash.之后將CipherData拆分成不大于8 KB的片段,分別為Piece 1,Piece 2,Piece3等多個(gè)片段.之后將RandomKey,CipherHash和CipherData的長(zhǎng)度合并成一個(gè)片段,記作Piece 0.如果任何一個(gè)片段的長(zhǎng)度不足8 KB,不足的部分用隨機(jī)字節(jié)補(bǔ)充.選擇8 KB的理由在于,在java運(yùn)行環(huán)境中,內(nèi)存池能夠分配的最小緩沖單位默認(rèn)為8 KB.

第三步,為每一個(gè)8 KB片段產(chǎn)生隨機(jī)UUID(version 4 UUID)[6],并為每一個(gè)片段加上時(shí)間戳標(biāo)簽,記作ExpirationTime.每一個(gè)珠,都由UUID、其對(duì)應(yīng)的片段和ExpirationTime構(gòu)成.使用分布式數(shù)據(jù)庫(kù)來(lái)進(jìn)行持久化存儲(chǔ).通過(guò)對(duì)比ExpirationTime和當(dāng)前的網(wǎng)絡(luò)時(shí)間,此數(shù)據(jù)庫(kù)會(huì)刪除過(guò)期或者失效的珠.對(duì)于ExpirationTime,用戶可以自行設(shè)置.但是如果同一條數(shù)據(jù)的所有珠存在同一個(gè)具體ExpirationTime,這會(huì)導(dǎo)致一個(gè)后果:攻擊者如果獲取了數(shù)據(jù)庫(kù)資料,就可以很輕松的區(qū)分哪些珠子屬于同一條數(shù)據(jù).因此一種延遲機(jī)制被采用來(lái)降低這種風(fēng)險(xiǎn):給每一個(gè)ExpirationTime隨機(jī)延時(shí)延遲0到3600秒,這樣可以提高復(fù)雜度,并使得珠之間有足夠的離散.

第四步,將片段中的UUID按順序結(jié)合起來(lái),獲得由uuid組成的線,稱作鏈,任何擁有鏈的用戶可以獲得所有的片段,通過(guò)RandomKey破譯CipherData,通過(guò)Piece0中的CipherHash破譯數(shù)據(jù).但是如果任何珠過(guò)期或者被刪除,即使你獲得了相應(yīng)的鏈,你也無(wú)法獲得正確的珠以及數(shù)據(jù).

以上4步的偽代碼展示如下:

算法. 數(shù)據(jù)加密與解密RandomKey = Generate ();CipherData = Encrypt (RandomKey,InputData);CipherHash = Hash (CipherData);Piece[0] = Combine (RandomKey,CipherHash,Lengthof(CipherData));

For n=1 To ＜Lengthof (CipherData)/(1024*8)＞Piece[n]= Split (CipherData,(n-1)*1024*8,(n)*1024*8);End For For Each Piece in Piece[n]UUID = GenerateUUID ();CreateBead(UUID,Piece,ExpirationTime.addSeconds(RandomDelay.ToSeconds ()));Strand = Strand + UUID;End For Strand = “SDD://” + Strand;Return Strand;

其中SSD (self-destructing data)鏈接將暴露出作為URL (Uniform Resource Locator),因此用戶可以以一個(gè)＜img＞標(biāo)簽的形式將其嵌入任何基于HTML(HyperText Markup Language)的文檔中.任何收到SSD鏈接的人可以使用支持HTML的Web瀏覽器來(lái)閱讀SSD信息.原型系統(tǒng)架構(gòu)展示如圖4.

3.3.2 印度紫檀種植管理。種植前應(yīng)安裝好排噴灌設(shè)施。挖坑規(guī)格為40 cm×40 cm×40 cm,在種植前30 d每坑施放3 kg經(jīng)堆漚的有機(jī)肥料，后回土種植。

圖4 原型系統(tǒng)架構(gòu)

但是HTML文本依賴于HTTP (HyperText Transfer Protocol)[7]中的GET方法,且最大長(zhǎng)度為2048個(gè)ASCII字符[8].這意味著我們無(wú)法顯示一個(gè)2054個(gè)字符的鏈作為HTML文本.

Geambasu使用火狐插件將密碼數(shù)據(jù)轉(zhuǎn)成純文包[9],基于此也可以將SSD形式的URI轉(zhuǎn)換成解密文本[10],但是在公眾號(hào)場(chǎng)景下這種方式不適用.因此,我們?cè)O(shè)計(jì)了一種二級(jí)索引機(jī)制,當(dāng)鏈創(chuàng)建成功后,對(duì)應(yīng)生成一個(gè)單個(gè)的UUID用來(lái)做映射.用戶可以通過(guò)此UUID和鏈來(lái)取得數(shù)據(jù).

總的來(lái)說(shuō),發(fā)送方通過(guò)這種模型將數(shù)據(jù)加密存儲(chǔ),并獲得相應(yīng)的鏈.接收方通此鏈,可以對(duì)離散的數(shù)據(jù)片段進(jìn)行重新整合,從而達(dá)到解密的目的.解密之后,數(shù)據(jù)會(huì)被判定為過(guò)期數(shù)據(jù),從而在存儲(chǔ)端被刪除.微信服務(wù)端提供的是身份驗(yàn)證,具體的加密解密工作由自毀服務(wù)器來(lái)完成.發(fā)送方和接收方通過(guò)公眾號(hào)為平臺(tái)進(jìn)行安全通信.可以將自毀服務(wù)器想象成一個(gè)盒子,一個(gè)人將要傳遞的數(shù)據(jù)撕成碎片放進(jìn)盒子里,盒子會(huì)對(duì)應(yīng)生成一把鑰匙和一段咒語(yǔ).當(dāng)另一個(gè)人拿著鑰匙將其打開后,看到只是一地碎紙,只有當(dāng)他念動(dòng)咒語(yǔ)后,碎紙才會(huì)自動(dòng)整合成一段完整的數(shù)據(jù),并在之后燃燒成灰.

3.3 數(shù)據(jù)安全自毀業(yè)務(wù)流程設(shè)計(jì)

數(shù)據(jù)安全自毀存儲(chǔ)流程如圖5所示,系統(tǒng)從發(fā)送方用戶獲取到四項(xiàng)數(shù)據(jù),過(guò)期時(shí)間TOE、接收方用戶唯一標(biāo)示符OpenID、原數(shù)據(jù)以及發(fā)送方的用戶唯一標(biāo)識(shí)符所對(duì)應(yīng)的一次性code值.其中前三項(xiàng)數(shù)據(jù)由發(fā)送方用戶填寫,code值則通過(guò)微信特有的第三方網(wǎng)頁(yè)授權(quán)OAuth2.0機(jī)制獲取,保證發(fā)送方用戶身份的真實(shí)有效.首先,使用接收方用戶唯一標(biāo)識(shí)符OpenID作為密鑰對(duì)文件數(shù)據(jù)進(jìn)行AES加密.完成一次加密后,使用隨機(jī)密鑰函數(shù)產(chǎn)生的密鑰對(duì)密文進(jìn)行2次AES加密,對(duì)加密后的密文進(jìn)行分片并將密鑰偽裝成一個(gè)密文分片,分片大小為1 K.隨機(jī)選擇一個(gè)分片添加時(shí)間戳屬性TOE,其他分片添加時(shí)間戳屬性.

TOE+random (3600*24*1000).由于文件數(shù)據(jù)還原需要所有的密文分片,此時(shí)間戳分配方案可以確保在用戶設(shè)定的過(guò)期時(shí)間后文件無(wú)法再被還原.同時(shí)同一文件密文分片之間的時(shí)間耦合性下降,防止可能的利用同一文件不用分片時(shí)間戳相同這一特性進(jìn)行分析和攻擊.給每個(gè)密文分片記錄產(chǎn)生唯一UUID,并將其作為記錄的主鍵存入服務(wù)器的數(shù)據(jù)庫(kù)中.根據(jù)分片的順序?qū)?duì)應(yīng)的UUID進(jìn)行2次哈希后組裝成SDD代理鏈接,SDD包裝成微信規(guī)定的圖文消息的XML格式發(fā)送給微信服務(wù)器,由微信服務(wù)器通過(guò)客服接口直接轉(zhuǎn)發(fā)給接收方用戶.用一開始接收到發(fā)送方的用戶唯一標(biāo)示對(duì)應(yīng)的code值向微信服務(wù)器換取發(fā)送方的OpenID標(biāo)識(shí)數(shù)據(jù)來(lái)源.服務(wù)器定時(shí)掃描數(shù)據(jù)庫(kù),刪除時(shí)間戳早于當(dāng)前時(shí)間的分片記錄.

數(shù)據(jù)安全自毀讀取流程如圖6所示,接收方用戶通過(guò)點(diǎn)擊圖文消息向服務(wù)器發(fā)送解密請(qǐng)求,服務(wù)器從接收方用戶獲取到指定SDD代理鏈接以及接收方身份所換取的對(duì)應(yīng)的一次性code值.code值通過(guò)微信特有的第三方網(wǎng)頁(yè)授權(quán)OAuth2.0機(jī)制獲取,保證接收方用戶身份的真實(shí)有效.使用一次性code值向微信授權(quán)中心換取對(duì)應(yīng)用戶的OpenID.服務(wù)器根據(jù)接收到的SDD代理鏈接向服務(wù)器數(shù)據(jù)庫(kù)申請(qǐng)相對(duì)應(yīng)的密文分片,若分片都沒(méi)有過(guò)期被刪除則按照順序讀取所有的分片使用隨機(jī)密鑰進(jìn)行的AES解密.使用之前換取到接收方用戶的OpenID作為密鑰進(jìn)行 2次AES解密,解密成功則根據(jù)文件的類型向用戶提供在線預(yù)覽服務(wù).

圖5 數(shù)據(jù)安全自毀存儲(chǔ)流程

3.4 應(yīng)用實(shí)例

通過(guò)微信公眾號(hào)發(fā)送安全自毀文件如圖7所示,用戶由微信公眾號(hào)下單的自定義菜單的上傳文件的選項(xiàng)進(jìn)去上傳文件頁(yè)面.一共有3項(xiàng)數(shù)據(jù)要求用戶填寫,分別是用戶所設(shè)定的文件安全自毀時(shí)間,所需要安全自毀的文件以及接收方用戶的OpenID.正確填寫后,點(diǎn)擊發(fā)送,若返回文件發(fā)送成功的提示則發(fā)送成功.

圖6 數(shù)據(jù)安全自毀讀取流程

圖7 微信公眾號(hào)文件發(fā)送頁(yè)面

通過(guò)微信公眾號(hào)接受安全自毀文件如圖8所示,接收方用戶接收到文件,點(diǎn)擊圖文消息,微信自動(dòng)驗(yàn)證當(dāng)前用戶身份,若用戶身份正確且文件沒(méi)有超過(guò)過(guò)期時(shí)間,則可以獲取到文件的在線預(yù)覽.

4 系統(tǒng)的安全性分析

4.1 在微信公眾號(hào)中的安全性分析

在數(shù)據(jù)安全自毀服務(wù)平臺(tái)設(shè)計(jì)方案中,文件數(shù)據(jù)本身只與數(shù)據(jù)安全自毀服務(wù)器進(jìn)行直接交互,并不會(huì)經(jīng)由微信服務(wù)器進(jìn)行轉(zhuǎn)發(fā),也就不會(huì)在微信中留下長(zhǎng)期的數(shù)據(jù)副本.客戶端以及數(shù)據(jù)安全自毀服務(wù)器之間的通信安全由TLS協(xié)議所保證,安全性高于微信所使用HTTP的通信.在微信的通信中,由文件的SDD代理鏈接作為解密憑證代為傳遞.在用戶試圖使用SDD代理鏈接作為解密憑證獲取原文件時(shí),我們使用基于的微信第三方網(wǎng)頁(yè)授權(quán)OAuth2.0 機(jī)制的來(lái)獲取用戶的身份,并將其OpenID做為解密密鑰使用.當(dāng)文件過(guò)期時(shí)間到達(dá)時(shí),數(shù)據(jù)安全自毀服務(wù)器會(huì)刪除保存在數(shù)據(jù)庫(kù)中過(guò)期的密文分片,此時(shí)SDD代理鏈接失效,原文件再也無(wú)法再被還原,有效的防止了可能的大量歷史文件的泄露.

圖8 微信公眾號(hào)文件發(fā)送頁(yè)面

接收方用戶的圖文消息都是直接由微信公眾平臺(tái)以客服消息的模式所發(fā)送,唯一的身份標(biāo)識(shí)符為雙方用戶在該微信公眾號(hào)中所特有的OpenID.由于微信公眾號(hào)OpenID的特性,即不同用戶對(duì)同一微信公眾號(hào)的OpenID不同,同一用戶對(duì)不同的微信公眾號(hào)OpenID也不同,攻擊者無(wú)法通過(guò)OpenID獲取到接收方或者發(fā)送方的其他個(gè)人信息,而獲取SDD鏈接需通過(guò)微信的身份驗(yàn)證機(jī)制才能正確的讀取文件,所以即使微信發(fā)送消息被攻擊者截獲分析也并不會(huì)對(duì)用戶造成任何安全性問(wèn)題.

4.2 在數(shù)據(jù)安全自護(hù)服務(wù)器端上的安全性分析

在用戶設(shè)定的過(guò)期時(shí)間內(nèi),文件數(shù)據(jù)受高安全性的加密方案所保護(hù).而當(dāng)有效期到達(dá)時(shí),文件的密文分片會(huì)被服務(wù)器端數(shù)據(jù)庫(kù)自動(dòng)刪除,文件無(wú)法再通過(guò)SDD代理鏈接被還原.下面給出過(guò)期時(shí)間內(nèi),隨機(jī)預(yù)言模型[11]下加密方案安全的簡(jiǎn)單證明.

假設(shè)加密明文所用的隨機(jī)密鑰產(chǎn)生函數(shù)是一個(gè)隨機(jī)預(yù)言機(jī),則攻擊者無(wú)法利用該預(yù)言機(jī)的弱點(diǎn)預(yù)測(cè)每次加密所用的密鑰,即該預(yù)言機(jī)所產(chǎn)生的隨機(jī)密鑰在其候選值域內(nèi)均勻分布.在無(wú)法預(yù)測(cè)密鑰的情況下,由于該加密方案中明文加密后的密文被分片成等長(zhǎng)的大小并且密鑰被偽裝成一個(gè)密文分片,所以服務(wù)器攻擊者將無(wú)法區(qū)別哪些分片是密文哪些分片是密鑰.假設(shè)密鑰數(shù)量遠(yuǎn)小于密文碎片數(shù)量,則認(rèn)為單個(gè)分片在概率上最有可能是密文碎片,此時(shí)攻擊者要尋找到密鑰相當(dāng)于只能暴力破解.所以對(duì)單個(gè)文件的密文密鑰分片來(lái)說(shuō)O(n)是窮舉加密算法密鑰空間的時(shí)間復(fù)雜度.

當(dāng)數(shù)量巨大的密文分片存儲(chǔ)入數(shù)據(jù)庫(kù)時(shí),數(shù)據(jù)庫(kù)中總分片數(shù)N將會(huì)足夠大,由于服務(wù)器攻擊者沒(méi)有解密憑證SDD代理鏈接,攻擊者若需要從分片中選擇屬于同一密文的密鑰與密文分片,也只能采取暴力破解.此時(shí),該加密方案CCA選擇密文攻擊[12,13]時(shí)間復(fù)雜度最好情況下是n(n-1)=O(n2),最壞情況下則是n!=O(nn).而CCA選擇密文攻擊的平均開銷是每n個(gè)分片的讀取開銷乘以(N!+N*(N+1))/2 復(fù)雜度是O(nn).即在隨機(jī)預(yù)言模型下攻擊該方案所需的時(shí)間開銷無(wú)法使用多項(xiàng)式時(shí)間計(jì)算,加密方案安全.

5 結(jié)論與展望

本文針對(duì)我國(guó)現(xiàn)在社交軟件中帶有敏感信息數(shù)據(jù)泄露的現(xiàn)狀,設(shè)計(jì)和實(shí)現(xiàn)了一種基于微信的數(shù)據(jù)安全自毀服務(wù)平臺(tái),完成了最基本的文件的加密存儲(chǔ)以及讀取功能,對(duì)該平臺(tái)的可行性進(jìn)行了驗(yàn)證.目前,該服務(wù)平臺(tái)主要支持圖片和pdf格式的預(yù)覽,如何支持更多格式的文件預(yù)覽以及進(jìn)一步豐富服務(wù)平臺(tái)的功能多樣性將是下一階段的研究重點(diǎn).