徐學(xué)東，季才偉

（1.長(zhǎng)春工程學(xué)院機(jī)電工程學(xué)院，長(zhǎng)春 130012；2.長(zhǎng)春易申軟件有限公司，長(zhǎng)春 130012）

0 引言

隨著計(jì)算機(jī)和網(wǎng)絡(luò)的高速發(fā)展，各類文檔普及電子化。相應(yīng)的文檔版權(quán)和安全技術(shù)也得到了快速發(fā)展，數(shù)字版權(quán)管理（DRM）是其中比較有代表性的技術(shù)。將DRM技術(shù)用于文檔安全管理，可以有效地防止未授權(quán)的用戶對(duì)電子文檔的非法獲取和使用［1］，如 Adobe Content Server、鐵卷、天盾等。這些產(chǎn)品均由客戶端、許可證服務(wù)器和內(nèi)容服務(wù)器等組成。文檔首先由打包工具加密，使用權(quán)限和密鑰保存在許可證中?？蛻舳藦膬?nèi)容服務(wù)器下載數(shù)據(jù)文檔，使用時(shí)必須從許可證服務(wù)器獲得對(duì)應(yīng)的許可證［2］。上述DRM文檔安全產(chǎn)品都存在2個(gè)固有的弱點(diǎn)：

（1）對(duì)DRM文檔的完整解密過(guò)程完全在客戶機(jī)上執(zhí)行，一旦客戶端被破解，則對(duì)于文檔的保護(hù)無(wú)從談起。

（2）DRM文檔在修改變更時(shí)難以在客戶端實(shí)時(shí)實(shí)現(xiàn)再加密處理，影響了文檔的可用性。

隨著網(wǎng)絡(luò)的普及和帶寬的大幅度提高，基于數(shù)據(jù)流技術(shù)實(shí)現(xiàn)本地業(yè)務(wù)遠(yuǎn)端實(shí)時(shí)執(zhí)行成為可能。本文就是應(yīng)用把軟件動(dòng)態(tài)變化的重要部分轉(zhuǎn)移到遠(yuǎn)端運(yùn)行這種設(shè)計(jì)理念，提出了“殼客戶端/實(shí)體服務(wù)端”（Shell Client/Solid Server，簡(jiǎn)稱SC/SS）模型，基于數(shù)據(jù)流技術(shù)實(shí)現(xiàn)客戶端關(guān)鍵模塊和加解密環(huán)節(jié)的遠(yuǎn)端處理，提高了客戶端軟件的防破解能力，同時(shí)解決了DRM文檔修改后同步打包的問(wèn)題。

1 相關(guān)工作

軟件遠(yuǎn)端執(zhí)行的相關(guān)技術(shù)很早就已經(jīng)實(shí)現(xiàn)了，比較典型的是RPC。但文檔等較大數(shù)字文件的遠(yuǎn)端處理受響應(yīng)時(shí)間的制約，目前尚未見(jiàn)到有成熟的產(chǎn)品或方案［3］。

我們?cè)谇捌谠M(jìn)行數(shù)據(jù)流實(shí)時(shí)處理技術(shù)方面的研究，在相關(guān)的成果中我們以數(shù)據(jù)流的最小化存儲(chǔ)空間開(kāi)銷和高速索引為目標(biāo)，設(shè)計(jì)出適合在內(nèi)存中并行處理的數(shù)據(jù)流操作樹(shù)和查詢操作樹(shù)的增量式索引更新算法，降低了數(shù)據(jù)流操作的時(shí)間復(fù)雜度。這些成果為電子文檔的實(shí)時(shí)遠(yuǎn)端處理提供了重要的技術(shù)基礎(chǔ)。

2 模型與總體設(shè)計(jì)

2.1 遠(yuǎn)端執(zhí)行的“殼客戶端/實(shí)體服務(wù)端”模型

傳統(tǒng)DRM文檔安全系統(tǒng)多采用C/S架構(gòu)模型，其缺點(diǎn)在于對(duì)客戶端的安全性依賴較大。盡管客戶端可以通過(guò)代碼加密、加殼等技術(shù)手段進(jìn)行保護(hù)，但如果遇到惡意破解者，仍可以通過(guò)反編譯等手段分析軟件的保護(hù)意圖，在適當(dāng)?shù)奈恢眉由咸D(zhuǎn)指令，跳過(guò)軟件的保護(hù)機(jī)制，破解客戶端［4］。

我們認(rèn)為把客戶端的關(guān)鍵模塊放到遠(yuǎn)程運(yùn)行，使之脫離破解者的控制，是實(shí)現(xiàn)系統(tǒng)安全的關(guān)鍵。在前期數(shù)據(jù)流技術(shù)的基礎(chǔ)上，我們提出了“殼客戶端/實(shí)體服務(wù)端”（Shell Client/Solid Server，簡(jiǎn)稱SC/SS）模型，如圖1所示。

圖1 SC/SS模型

我們將DRM中完整意義上的客戶端分為框架Framework和關(guān)鍵模塊Key Part 2部分。殼客戶端主要是Framework，我們稱之為Shell Client，它運(yùn)行時(shí)在形式上執(zhí)行完整客戶端的業(yè)務(wù)，實(shí)質(zhì)上主要負(fù)責(zé)實(shí)現(xiàn)文檔數(shù)據(jù)流的組織和信息采集。Key Part部署在服務(wù)端并執(zhí)行，負(fù)責(zé)客戶端關(guān)鍵代碼和文檔加解密環(huán)節(jié)的執(zhí)行。兩者通過(guò)數(shù)據(jù)流技術(shù)實(shí)現(xiàn)實(shí)時(shí)交互，其中服務(wù)端遠(yuǎn)端執(zhí)行后的數(shù)據(jù)流被殼客戶端重組為明碼文檔在鎖定的內(nèi)存區(qū)內(nèi)運(yùn)行。Shell Client和Solid Server使用的RPC調(diào)用接口為SOAP協(xié)議，通訊協(xié)議使用雙向SSL，保障通訊數(shù)據(jù)的安全性［4］。此方案可以適用于所有操作系統(tǒng)，并且可以隨意調(diào)整接口，穿過(guò)防火墻的攔截。

2.2 SC/SS模型的技術(shù)實(shí)現(xiàn)與創(chuàng)新

實(shí)現(xiàn)方案為將原來(lái)的客戶端文件通過(guò)程序分析從所保護(hù)的文件中分解出若干個(gè)大小合適的代碼區(qū)塊，其中代碼區(qū)塊可以制定，也可以自由選取。轉(zhuǎn)移區(qū)塊的數(shù)量也可以靈活設(shè)定，這樣在保護(hù)不同的程序文件之間就可以存在差異性，保護(hù)更有針對(duì)性，不存在現(xiàn)有外殼加密技術(shù)的破解過(guò)程的相似性。

提取分解出的代碼區(qū)塊轉(zhuǎn)移到遠(yuǎn)端服務(wù)器中。在被移去代碼區(qū)塊的程序空洞位置通過(guò)文件代理模塊和代碼區(qū)塊之間建立對(duì)應(yīng)關(guān)系，保證在程序運(yùn)行的過(guò)程中仍為完整的應(yīng)用程序。代碼填充可采用多種方式，如專用的遠(yuǎn)端模塊功能調(diào)用、參數(shù)信息等。

該方案的創(chuàng)新性在于將DRM客戶端程序分解為2部分，其中分解出的關(guān)鍵部分放置到遠(yuǎn)端服務(wù)器，其余部分在客戶端機(jī)器運(yùn)行，2部分間通過(guò)網(wǎng)絡(luò)通訊建立相互調(diào)用關(guān)系，從而使客戶端無(wú)法擺脫服務(wù)端獨(dú)立完成對(duì)數(shù)字內(nèi)容的操作，從而防止了破解者對(duì)安全系統(tǒng)的控制。

2.3 系統(tǒng)的總體架構(gòu)

如圖2所示，系統(tǒng)包括安全服務(wù)器軟件和客戶端軟件2部分。安全服務(wù)器負(fù)責(zé)用戶的身份認(rèn)證、權(quán)限控制，客戶端關(guān)鍵模塊的運(yùn)行，DRM文檔打包、解密和用戶行為審計(jì)。客戶端軟件負(fù)責(zé)組織文檔數(shù)據(jù)流，與安全服務(wù)器進(jìn)行交互，采集客戶機(jī)信息發(fā)送給安全服務(wù)器，并監(jiān)控電子文件的使用情況，其中將加解密模塊分解轉(zhuǎn)移至遠(yuǎn)端服務(wù)器運(yùn)行。

圖2 安全系統(tǒng)總體架構(gòu)

客戶端還通過(guò)文件系統(tǒng)過(guò)濾器驅(qū)動(dòng)程序，從底層監(jiān)測(cè)用戶對(duì)文檔的操作，包括拷貝、讀取、修改等，阻斷超出允許權(quán)限的操作，并向安全服務(wù)器提供詳細(xì)描述，以備查詢。對(duì)于惡意行為，可以對(duì)服務(wù)端進(jìn)行報(bào)警。

3 系統(tǒng)實(shí)現(xiàn)的關(guān)鍵技術(shù)

3.1 加解密的遠(yuǎn)端處理實(shí)現(xiàn)

DRM文檔加解密環(huán)節(jié)可基于SC/SS模型的實(shí)現(xiàn)過(guò)程如下：

（1）Shell Client在用戶通過(guò)驗(yàn)證后啟動(dòng)文檔，以流模式將數(shù)據(jù)進(jìn)行序列化處理，對(duì)字節(jié)流進(jìn)行壓縮后通過(guò)RPC傳輸。

（2）服務(wù)端接收到數(shù)據(jù)流后依據(jù)特定連接策略生成查詢操作樹(shù)，分解數(shù)據(jù)塊后執(zhí)行加解密算法，并建立通信安全通道。

（3）解密數(shù)據(jù)流通過(guò)建立通信安全通道，通過(guò)SSL加密流的方式將文檔傳輸至客戶端的安全內(nèi)存區(qū)。

（4）Shell Client在鎖定安全區(qū)對(duì)數(shù)據(jù)流反序列化處理，并利用數(shù)據(jù)流上的頻繁項(xiàng)處理算法，在處理流中加入負(fù)載脫落算子，實(shí)現(xiàn)有效的負(fù)載脫落。確保在網(wǎng)絡(luò)流量有限的情況下提高客戶端文檔響應(yīng)效率。該技術(shù)將另文介紹。

上述模式下，用戶不通過(guò)身份驗(yàn)證無(wú)法獲得在服務(wù)端對(duì)文檔進(jìn)行處理的權(quán)限，由于加解密模塊和密鑰在遠(yuǎn)端，客戶端無(wú)法擺脫服務(wù)端對(duì)文檔的處理。在邏輯上阻斷了在客戶端獨(dú)立破解被保護(hù)文檔的可能性。

3.2 系統(tǒng)密鑰體系

系統(tǒng)采用加密卡實(shí)現(xiàn)文檔打包加解密，密鑰分為系統(tǒng)主密鑰PEK、文件保護(hù)密鑰FEK和用戶證書(shū)密鑰UCK。

電子文檔通過(guò)FEK加密保護(hù)，每一個(gè)文檔記錄對(duì)應(yīng)一個(gè)單獨(dú)的FEK。FEK通過(guò)PEK加密存儲(chǔ)，PEK還可保護(hù)系統(tǒng)中的敏感數(shù)據(jù)。通過(guò)數(shù)字信封的形式分發(fā)FEK，數(shù)字信封以用戶的證書(shū)密鑰（UCK）加密保護(hù)［5］。用戶配發(fā) USBKEY，其中保存數(shù)字證書(shū)和私鑰。其關(guān)系見(jiàn)圖3。

圖3 密鑰關(guān)系圖

圖4 文檔的應(yīng)用流程

4 系統(tǒng)應(yīng)用與評(píng)價(jià)

4.1 DRM文檔的應(yīng)用流程

如圖4所示，用戶首先通過(guò)客戶端軟件登錄安全服務(wù)器進(jìn)行身份認(rèn)證。文檔的解密通過(guò)加解密Key Part實(shí)現(xiàn)，客戶端通過(guò)RPC將密文以數(shù)據(jù)流方式發(fā)至服務(wù)器，服務(wù)器對(duì)解密密文，再以明文數(shù)據(jù)流實(shí)時(shí)返回客戶端。明文在客戶機(jī)安全內(nèi)存區(qū)中存在，由進(jìn)程獨(dú)占鎖定保護(hù)，防止外部進(jìn)程訪問(wèn)。用戶可以進(jìn)行權(quán)限內(nèi)的訪問(wèn)操作，同步客戶端軟件底層監(jiān)控用戶的操作，并將操作記錄發(fā)送至安全服務(wù)器軟件。操作后關(guān)閉文檔，內(nèi)存中的明文自動(dòng)刪除，仍以密文形式存在于客戶機(jī)器上。

通訊過(guò)程使用雙向SSL安全加密通道，保障明文及密文的文件數(shù)據(jù)流的安全性。這樣離開(kāi)了服務(wù)端的支持，客戶端無(wú)法單方面解密文件?？蛻舳嗽谑褂眠^(guò)程中也未獲取密鑰，也就不存在密文被破解的可能，同時(shí)排除了數(shù)據(jù)流在網(wǎng)絡(luò)傳輸過(guò)程中被抓包竊取及修改的可能性。

4.2 DRM文檔修改同步打包流程

通過(guò)數(shù)據(jù)流遠(yuǎn)端加解密實(shí)現(xiàn)技術(shù)解決DRM文檔修改同步打包流程如下：

（1）用戶獲得名為密文V1.0的可修改DRM文檔，通過(guò)身份認(rèn)證后系統(tǒng)通過(guò)遠(yuǎn)端處理機(jī)制在客戶端還原明文V1.0，在進(jìn)程鎖定的安全內(nèi)存區(qū)運(yùn)行。

（2）用戶修改文檔，確定保存后形成明文V1.1版本并提交打包請(qǐng)求。

（3）打包請(qǐng)求執(zhí)行遠(yuǎn)端處理機(jī)制，由服務(wù)器依據(jù)加密策略設(shè)定新的密鑰，進(jìn)行二次加密，加密后的文件數(shù)據(jù)返回客戶端形成修改后的密文V1.1版本，并在服務(wù)器存檔。

所有操作記錄保存在服務(wù)器操作日志中，便于審計(jì)。

4.3 系統(tǒng)應(yīng)用評(píng)價(jià)

研究成果在吉林省某設(shè)計(jì)單位進(jìn)行了試點(diǎn)應(yīng)用。運(yùn)行環(huán)境為100 M局域網(wǎng)，由2臺(tái)Dell 5550服務(wù)器，10臺(tái)客戶機(jī)組成。一臺(tái)服務(wù)器部署安全服務(wù)器系統(tǒng)，并配置得安加密系統(tǒng)一套，另一臺(tái)服務(wù)器作為文檔服務(wù)器。

測(cè)試中，10臺(tái)客戶機(jī)均執(zhí)行不同大小的10個(gè)CAD文檔打開(kāi)、修改、存儲(chǔ)操作請(qǐng)求。測(cè)試目標(biāo)為通過(guò)對(duì)網(wǎng)絡(luò)流量的監(jiān)控，獲得身份驗(yàn)證、文檔加解密和存儲(chǔ)平均延遲，測(cè)試結(jié)果如表1所示。

表1 系統(tǒng)測(cè)試

分析測(cè)試數(shù)據(jù)，其延遲主要出現(xiàn)在文檔遠(yuǎn)端加解密環(huán)節(jié)。因此改善硬件性能將能有效改善系統(tǒng)性能，較好地滿足應(yīng)用需求。

5 結(jié)語(yǔ)

普通的DRM文檔安全產(chǎn)品中，文檔的解密和身份認(rèn)證等處理都在客戶端實(shí)現(xiàn)，一旦客戶端被破解，對(duì)DRM文檔的保護(hù)就無(wú)從談起。同時(shí)由于客戶端條件的限制，難以實(shí)時(shí)對(duì)文檔進(jìn)行打包加密處理，安全文檔的可用性受到極大制約。

針對(duì)這些問(wèn)題，本文提出了SC/SS模型，基于數(shù)據(jù)流技術(shù)實(shí)現(xiàn)文檔遠(yuǎn)端加解密和客戶端防破解，并在此基礎(chǔ)上提出了一整套的文檔安全解決方案，滿足電子文件全生命周期的安全管理。試點(diǎn)測(cè)試表明，該系統(tǒng)在保證性能的情況下較好地解決了上述的2個(gè)問(wèn)題。

［1］蔡皖東，田廣利，段琪，等.基于DRM的電子文檔保護(hù)系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)［J］.微電子學(xué)與計(jì)算機(jī)，2005，22（7）：161－164.

［2］Lin E T，Eskieioglu A M，Lagendijk R L，etc.Advanecs in Digital Video Content Protection［J］.Proceedings of the IEEE，2005，93（1）：171一183.

［3］鐘勇，秦小麟，鄭吉平，等.一種靈活的使用控制授權(quán)語(yǔ)言框架［J］.計(jì)算機(jī)學(xué)報(bào)，2006，29（8）：1408－1418.

［4］Kuhlmann D，Gehring RA.Trusted platforms，DRM，and beyond［A］.Becker E.Digital Right s Management：Technological，Economic，Legal and Political Aspects，Lecture Notes in Computer Science 2770［C］，Berlin：Springer－Verlag，2003：178－205.

［5］Bettini C，Jajodia S，Wang XS，etc.Provisions and obligations in policy management and security applications［A］.Bernstein PA，Loannidis YE，Ramakrishnan R，etc.Proc.of the 28th Int'l Conf.on Very Large Data Bases［C］.Hong Kong：Morgan Kaufmann Publishers，2002：502－513.

［6］Barth A，Datta A，Mitchell JC，etc.Privacy and contextual integrity：Framework and application［A］.IEEE Press Proc.of the 27th IEEE Symp.on Security and Privacy［C］.New York：IEEE Press，2006：184－198.

［7］Chong CN，Ren B，Doumen J，etc.Hartel PH，Corin R.License protection with a tamper－resistant token［A］.Chae HL，Moti Y.Proc.of the 5th Int'l Workshop Information Security Applications［C］.Heidelberg：Springer－Verlag，2004：223－227.