龍 奔,孫志宏

(江蘇自動化研究所 電子設(shè)備事業(yè)部,連云港 222002)

1 引言

隨著信息技術(shù)的快速發(fā)展,大型復(fù)雜軟件的功能需求不斷增加,規(guī)模也越來越大.在開發(fā)環(huán)境的構(gòu)建過程中,集成部署過程是重要的一環(huán),其部署效率和安全性也逐漸引起了開發(fā)者的重視.

目前,大型復(fù)雜軟件的開發(fā)工作主要采用分布式協(xié)同開發(fā)的方式實現(xiàn).由各家單位根據(jù)自身專業(yè)所長,通過人員溝通、集中試驗、集成聯(lián)調(diào)等方式展開協(xié)同開發(fā),并結(jié)合過程管理和協(xié)議通訊,實現(xiàn)軟件的集成部署.然而,實際工作環(huán)境對于大型復(fù)雜軟件的可靠性和安全性存在著極高的要求,尤其在航空航天、深海探測以及核工業(yè)安全等領(lǐng)域,如果出現(xiàn)質(zhì)量問題或者安全問題,將會造成災(zāi)難性的后果.對于開發(fā)者而言,隨著軟件規(guī)模的增大,構(gòu)建高效的軟件開發(fā)環(huán)境不僅能夠針對軟件的開發(fā)過程進行有效的控制,而且能夠提高開發(fā)過程的規(guī)范化,幫助開發(fā)團隊開發(fā)出高質(zhì)量的軟件.

構(gòu)建高效的軟件開發(fā)環(huán)境勢必需要部署過程,因此,部署相關(guān)的問題也隨之而來.該類問題主要體現(xiàn)在兩個方面:

(1)傳統(tǒng)的軟件開發(fā)環(huán)境需要實施人員進行手動部署,該方式無法保證軟件整體的部署質(zhì)量.同時,在大規(guī)模部署時,由于相互之間通信對象的增多,測試過程中未暴露的缺陷可能會引起大量的異常,嚴重地影響了軟件開發(fā)的效率.

(2)大型復(fù)雜軟件的開發(fā)任務(wù)逐步呈現(xiàn)高密度態(tài)勢,往往存在開發(fā)任務(wù)重、時間緊、周期長的特點,同時對軟件的正確性、健壯性和安全性的要求越來越高,這就對集成部署工作提出了更加安全高效的要求.

文獻[1]研究了目前主流的幾種軟件部署方法,其中,軟件部署工具擁有較為統(tǒng)一的部署流程,可實現(xiàn)軟件的快速部署,并且滿足開發(fā)環(huán)境多樣化的需求.目前,國內(nèi)外已存在不少軟件部署工具,按照分發(fā)和部署策略劃分,可歸為以下3類[2]:包部署工具、通用產(chǎn)品部署工具和特定供應(yīng)商產(chǎn)品部署器.其中,包部署工具一般適用于開源系統(tǒng),基本沒有安全措施,無法保證集成部署過程的安全性.文獻[3]提到的InstallShield是一種通用產(chǎn)品部署器,在軟件安裝過程中支持多種分發(fā)方式,并且可提供全程的圖形功能.但是,InstallShield存在封包格式不公開和占用資源較大等問題,并且安全機制不完善,無法滿足安全需求.特定供應(yīng)商產(chǎn)品部署器提供的功能有限,一般只適用于特定產(chǎn)品的部署更新.該類部署工具存在的一些身份驗證和完整性驗證等安全機制,但是僅針對特定的產(chǎn)品,不具備通用性.

在軟件部署策略研究方面,文獻[4]提出了一種通用的組件部署模型,該模型基于人工智能中的規(guī)劃算法實現(xiàn)組件的部署計劃.文獻[5]綜合多種影響軟件服務(wù)質(zhì)量的因素,并針對軟件部署策略提出了一種通用的多目標優(yōu)化算法,但是該算法需要借助其他工具支持.文獻[6]提出了一種軟件部署優(yōu)化的策略,該方法利用UML模型對系統(tǒng)進行建模處理,可有效地提高系統(tǒng)的性能和可靠性.雖然軟件部署策略方面的研究較為豐富,但是以上研究方案未針對部署環(huán)境的復(fù)雜性和安全性作出討論,其部署效率和安全性未得到驗證.

文獻[7]提出的自治計算架構(gòu)是當前軟件管理方面的熱點,該架構(gòu)提供了一種可實現(xiàn)軟件自我管理的機制,可在盡可能減少人為干預(yù)的情況下,實現(xiàn)系統(tǒng)環(huán)境的自主管理.然而,由于存在架構(gòu)規(guī)格描述、程序傳遞、事件記錄等技術(shù)上的障礙,自治計算架構(gòu)還無法在系統(tǒng)環(huán)境下實現(xiàn)軟件的自我部署功能.

通過上述的研究分析可知,目前在大型復(fù)雜軟件開發(fā)環(huán)境下,還缺乏高效且安全的方案來解決軟件集成部署的問題.針對該問題,本文嘗試給出一種基于度量認證的協(xié)同可信部署(Cooperative Trusted Deployment based on Metric Authentication,CTDMA)方案,其主要思想是:首先通過一種安全關(guān)聯(lián)協(xié)議在軟件部署雙方之間建立可信的安全傳輸通道,然后宿主機會根據(jù)統(tǒng)一的打包部署規(guī)范,將部署包通過安全傳輸通道傳送給相應(yīng)的目標機,最后目標機經(jīng)過解析,并利用一種改進型的完整性度量算法對部署包進行完整性和一致性確認,確認通過后,完成集成部署工作.該方案通過建立統(tǒng)一的打包部署規(guī)范,可保證整個部署過程可復(fù)制可預(yù)期,通過優(yōu)化完整性度量算法,能夠有效地提高軟件集成部署的效率.此外,安全關(guān)聯(lián)協(xié)議的應(yīng)用以及部署包的度量認證機制可極大地提高數(shù)據(jù)傳輸?shù)目尚判?

2 相關(guān)技術(shù)研究

2.1 安全關(guān)聯(lián)協(xié)議

Diffie和Hellman[8]提出了一種密鑰交換算法,該算法能夠幫助通信雙方安全地協(xié)商出共享密鑰,以便在后續(xù)通信過程中使用該密鑰對信息進行加解密.

在數(shù)學問題上,計算離散對數(shù)的困難性是保證Diffie-Hellman算法有效性的基礎(chǔ),在進行密鑰交換前,通信雙方首先需要確定q和α,其中,α和q是兩個公開的整數(shù)(該整數(shù)也可由通信雙方在密鑰交換過程中協(xié)商得出),α是q的本原根,其冪可產(chǎn)生1到q之間的所有整數(shù).

在分布式協(xié)同開發(fā)環(huán)境下,利用Diffie-Hellman算法進行密鑰交換,可保證宿主機和目標機之間通信的安全性,如圖1所示,其密鑰協(xié)商的過程如下.

圖1 宿主機和目標機的密鑰協(xié)商過程

(1)分布式開發(fā)環(huán)境下的各計算節(jié)點彼此之間可進行身份認證.宿主機隨機選擇一個整數(shù)Xh(Xh

(2)目標機接收到信息后,隨機選擇一個整數(shù)Xt(Xt

(3)通信雙方分別接收到對方的臨時公鑰后,計算共享密鑰,其中,宿主機端的共享密鑰為目標機端的共享密鑰為至此,通信雙方完成了密鑰交換工作.

在計算共享密鑰的過程中,雖然宿主機和目標機使用的部分參數(shù)不同,但是其計算結(jié)果相同,根據(jù)模運算定律,其證明如下:

密鑰交換結(jié)束之后,通信雙方可利用共享密鑰加密通信信息,建立一條安全的信息傳輸通道,每一次會話結(jié)束后,通信雙方需要按照以上過程,重新協(xié)商共享密鑰.

2.2 可部署軟件建模方法研究

(1)現(xiàn)有軟件描述語言分析

現(xiàn)有的可部署軟件建模方法有開放式軟件描述(Open Software Description,OSD)、信息管理格式(Management Information Format,MIF)、可部署軟件描述(Deployable Software Description,DSD)3種.通過分析,這3種部署軟件建模方法的優(yōu)缺點如表1所示.

表1 部署軟件建模方法總結(jié)

通過上述比較可知,可部署軟件描述(DSD)對于部署軟件規(guī)范化描述的可擴展性和支持性較好,本文提出的方案可采用該種方式.

(2)可部署軟件規(guī)范化描述

DSD 將待部署軟件和目標機配置信息建模成嵌套的屬性集合,其規(guī)范化描述可以由以下4方面組成:

1)部署軟件的信息描述

部署軟件信息包括軟件基本信息和軟件特征信息兩個部分,其中,XML文件格式的屬性描述待部署軟件的序列,描述系統(tǒng)標識,均位于軟件信息描述的外側(cè),內(nèi)部嵌套表示其他信息的標簽.

軟件基本信息:軟件名稱、軟件描述、軟件版本號、軟件生產(chǎn)商等.

軟件特征信息:軟件特征碼,該部分可記錄部署包完整性度量值,用于目標機進行解析驗證.

2)目標機開發(fā)環(huán)境約束描述

目標機的開發(fā)環(huán)境包含目標機的系統(tǒng)和硬件兩個部分,在打包部署過程中,為保證待部署軟件在目標環(huán)境下安全穩(wěn)定地運行,需要滿足目標機端的軟硬件環(huán)境需求.

屬性位于描述的最外側(cè),表示目標機開發(fā)環(huán)境的硬件和系統(tǒng)的約束集合,每一對表示一類信息.該部分包括依賴條件、軟件描述等.

其中,表示目標機當前的開發(fā)環(huán)境,包括操作系統(tǒng)(OS)、硬盤大小(Disksize)、內(nèi)存大小(Memory)等.

3)軟件依賴約束描述

屬性位于描述的最外側(cè),表示目標機開發(fā)環(huán)境的硬件和系統(tǒng)的約束集合,每一對表示一類信息.該部分包括依賴條件、軟件描述等.

該部分包括依賴條件、軟件序列、軟件描述、解決方案等部分組成,其中,每一個屬性表示一個依賴的軟件,表示目標機環(huán)境,即目標機內(nèi)是否存在該軟件.表示依賴軟件需要執(zhí)行的動作,如果顯示該軟件尚未安裝,則應(yīng)取值Install,對該軟件執(zhí)行安裝操作.

4)軟件部署行為描述

軟件部署行為是指在軟件部署過程中,操作系統(tǒng)需要執(zhí)行的動作.一般情況下,軟件部署過程中,系統(tǒng)需要預(yù)先關(guān)閉一系列進程,部署結(jié)束后,系統(tǒng)需要重新啟動操作系統(tǒng),這些均是軟件部署行為.其外部屬性為,每一對表示一種需要執(zhí)行的動作,包含:動作名稱、動作內(nèi)容、判別時間、動作描述等內(nèi)容,其中,表示需要執(zhí)行的動作,如Restart,表示系統(tǒng)重啟.表示該動作執(zhí)行的時間,如After Deployment,表示系統(tǒng)重啟動作在部署完成后進行.

(3)完整性度量技術(shù)研究

在軟件的集成部署過程中,部署包的完整性度量是影響部署效率的主要因素,并且部署包越大,完整性度量計算的耗時就越高,對完整性度量算法進行優(yōu)化,是提高軟件集成部署效率的有效方法.

由于散列算法具有不可逆和抗碰撞攻擊的能力,并且輸出長度固定、安全性好,一般采用散列算法作為完整性度量算法.散列算法主要由預(yù)處理過程和散列值計算兩個部分組成,其中,預(yù)處理過程可分為3部分:消息填充、分割已填充消息以及設(shè)置散列值計算初始值.

根據(jù)組成特點可知,散列算法存在可并行性,利用線程級并行和存儲級并行技術(shù)對算法進行改進,可提高算法的計算效率.其改進思想是:根據(jù)散列度量算法的特點,利用線程級的并行技術(shù)將處理任務(wù)進行劃分,針對待度量的數(shù)據(jù),將其分成均勻的數(shù)據(jù)塊并交給不同的線程進行流水執(zhí)行,通過存儲級并行技術(shù)實現(xiàn)訪問隱藏.改進的并行算法流程如圖2所示.

圖2 并行算法流程圖

改進后的算法可分為Read線程和Update線程兩類進行并行處理,其中,Read線程通過數(shù)據(jù)預(yù)讀取[9]的方式讀取劃分好的數(shù)據(jù)塊,Update線程則按順序依次將讀取的數(shù)據(jù)塊進行運算處理.其執(zhí)行流程如下:

(1)設(shè)置一個共享緩沖區(qū),其長度為n,大小為n×m個字節(jié),其中,m值的大小決定并行計算中流水粒度的大小;

(2)設(shè)計一個計數(shù)信號,并初始化為0,利用該計數(shù)信號保證兩個線程之間的同步性;

(3)創(chuàng)建兩個線程,分別為Read線程和Update線程,Read線程以數(shù)據(jù)預(yù)讀取的方式將均勻劃分的待度量數(shù)據(jù)塊讀入共享緩沖區(qū)中,Update線程針對共享緩沖區(qū)內(nèi)的數(shù)據(jù)進行順序運算處理;

(4)隨著Read線程執(zhí)行寫入緩沖區(qū)操作,計數(shù)信號不斷累加,如果緩沖區(qū)已滿,則Read線程停止寫入;

(5)隨著Update線程對緩沖區(qū)內(nèi)的數(shù)據(jù)執(zhí)行順序運算處理,計數(shù)信號不斷遞減,當緩沖區(qū)為空時,則Read線程停止等待,兩個線程之間可通過判斷計數(shù)信號實現(xiàn)同步.

此外,改進后的完整性度量算法利用設(shè)置私有計數(shù)器的方式可有效地減少對臨界區(qū)的訪問次數(shù),同時也可以避免鎖機制引起的死鎖事件.在線程同步過程中,Usleep(1)函數(shù)可減少同步開銷,隱藏訪問操作并最終得到度量結(jié)果.

3 CTDMA方案設(shè)計

3.1 可部署軟件建模方法研究

隨著軟件規(guī)模越來越大,復(fù)雜性也越來越高,開發(fā)者希望優(yōu)化軟件集成部署方法,提高軟件的開發(fā)效率,并保證部署過程的安全性.鑒于此,本文的研究思路是基于Diffie-Hellman密鑰交換算法協(xié)商出共享密鑰,在宿主機和目標機端建立一條安全傳輸通道,從而在開放式的網(wǎng)絡(luò)環(huán)境下保證部署信息傳輸?shù)陌踩?在集成部署方面,本文利用可部署軟件描述(DSD)語言為待部署軟件建立統(tǒng)一的打包部署規(guī)范,可幫助軟件進行自動集成部署,同時利用改進的完整性度量算法,可有效地提高部署雙方的計算效率.

3.2 CTDMA方案系統(tǒng)模型

針對分布式協(xié)同開發(fā)環(huán)境的特點,CTDMA方案的系統(tǒng)模型分為兩個部分:軟件協(xié)同部署服務(wù)器(Collaborative Deployment Server,CDS)和軟件協(xié)同部署客戶端(Collaborative Deployment Client,CDC).CTDMA方案系統(tǒng)模型交互示意圖如圖3所示.

圖3 CTDMA方案模型交互示意圖

軟件協(xié)同部署服務(wù)器(CDS):在分布式開發(fā)環(huán)境下,軟件協(xié)同部署服務(wù)器主要安裝在宿主機端,其功能主要分為以下4部分:

(1)根據(jù)開發(fā)者請求,與待部署的目標機建立安全關(guān)聯(lián);

(2)管理目標機信息庫、可部署軟件庫以及部署策略庫;

(3)根據(jù)部署策略庫提供的規(guī)范化描述方法將待部署軟件生成部署包和部署描述文件;

(4)將部署包和部署描述文件發(fā)送給目標機端并根據(jù)目標機端的部署情況作出響應(yīng).

軟件協(xié)同部署服務(wù)器包含以下幾個模塊:

目標機信息庫(Client Information Base,CIB):該模塊主要存儲宿主機所在分布式開發(fā)環(huán)境下所有目標機節(jié)點的軟硬件信息,可根據(jù)實際情況及時作出更新.

可部署軟件庫(Deployed Software Base,DSB):該模塊存儲開發(fā)環(huán)境構(gòu)建所需的軟件安裝包、軟件依賴文件以及軟件描述信息.

部署策略庫(Policy Base,PB):該模塊可提供軟件部署策略,幫助待部署軟件生成軟件描述文件,主要依據(jù)包括待部署軟件信息、目標機端的軟硬件環(huán)境以及規(guī)范化描述方法.

部署管理器(Deployment Manager,DM):該模塊是軟件協(xié)同部署服務(wù)器的核心,負責接收開發(fā)者的軟件部署請求,與目標機端建立安全關(guān)聯(lián),并調(diào)用其他模塊完成部署包的生成、發(fā)送和安裝工作.

軟件協(xié)同部署客戶端(CDC):在分布式開發(fā)環(huán)境下,軟件協(xié)同部署客戶端主要安裝在目標機端,其功能主要分為以下4部分:

(1)驗證宿主機身份,與宿主機端建立安全關(guān)聯(lián);

(2)獲取目標機端的軟硬件信息,發(fā)送給協(xié)同部署服務(wù)器;(3)接收宿主機端發(fā)送的部署包和軟件描述文件;(4)驗證部署包的可信性,并根據(jù)軟件描述文件安裝相應(yīng)軟件協(xié)同部署客戶端包含以下幾個模塊:

監(jiān)控器(Monitor):該模塊的主要功能是監(jiān)控部署包的安裝情況并將部署結(jié)果返回至服務(wù)器,以便服務(wù)器根據(jù)安裝情況作出響應(yīng).

目標采集器(Target Collector,TC):該模塊可獲取目標機端當前的軟硬件信息,并將該信息返回至服務(wù)器端.

軟件安裝器(Software Installers,SI):該模塊可根據(jù)軟件描述文件提供的依賴關(guān)系安裝部署包內(nèi)的軟件.

目標管理器(Target Manager,TM):該模塊是軟件協(xié)同部署客戶端的核心,負責驗證宿主機的身份,與宿主建立安全關(guān)聯(lián),并調(diào)用其他模塊完成部署包的解析、驗證和安裝工作.

3.3 CTDMA方案詳細設(shè)計流程

CTDMA方案的詳細設(shè)計流程如下:

流程1.協(xié)同部署服務(wù)器接收開發(fā)者請求,與待部署的目標機客戶端建立安全關(guān)聯(lián).

在分布式開發(fā)環(huán)境下,協(xié)同部署服務(wù)器(CDS)和協(xié)同部署客戶端(CDC)的身份認證工作已完成,并且已知公開的素數(shù)q 及其本原根α.根據(jù)Diffie-Hellman密鑰交換算法,CDS端與CDC端需要協(xié)商共享密鑰,建立一條安全傳輸通道.

具體操作如下:

(1)CDS端選擇一個隨機整數(shù)Xs作為自身私鑰,計算臨時公鑰Ys,并發(fā)送給CDC端,表示如下:

(2)CDC端隨機選擇一個隨機整數(shù)Xc作為自身私鑰,計算臨時公鑰Yc,并發(fā)送給CDS端,表示如下:

(3)通信雙方接收到對方的臨時公鑰后,計算共享密鑰,其中,CDS的共享密鑰為Ks,目標機端的共享密鑰為Kc,Ks=Kc,至此,通信雙方完成了密鑰交換工作,其表示方法和證明如下:

至此,通信雙方之間的密鑰交換工作結(jié)束,CDS端和CDC端可利用共享密鑰K 對部署信息進行加解密,以保證通信信息的安全性.

流程2.驗證目標機的平臺信息.

在進行集成部署工作之前,CDS端首先需要保證CIB內(nèi)的信息與目標機環(huán)境相一致.

具體做法如下:

(1)TM調(diào)用T 收集目標機端當前的軟硬件信息,設(shè)為m,使用共享密鑰K加密該信息,生成密文信息c,并發(fā)送給DM.

(2)DM接收到密文信息c 后,利用共享密鑰K解密,將解密信息與CIB內(nèi)存儲的信息進行對比.

(3)如果信息一致,DM則執(zhí)行后續(xù)部署,如果不一致,DM需要對CIB進行更新,以保持部署雙方信息的一致性.

流程3.CDS端生成部署包及軟件描述文件.

CDS端需要針對待部署軟件的特點和目標機的軟硬件環(huán)境,按照可部署軟件描述方法生成部署包和軟件描述文件.

具體做法如下:

(1)DM 根據(jù)開發(fā)者的部署請求查詢DSB,如果DSB內(nèi)存在待部署軟件,則繼續(xù)執(zhí)行,否則,停止部署工作;

(2)DM 查詢CIB內(nèi)的目標機信息和DSB內(nèi)的軟件配置信息,并根據(jù)PB 提供的軟件部署策略,寫入軟件約束依賴描述和平臺信息約束描述,生成軟件部署包和軟件描述文件;

(3)DM 利用改進后的完整性度量算法對部署包進行完整性度量計算,并將度量結(jié)果寫入軟件描述文件的相應(yīng)屬性標簽內(nèi);

(4)DM 利用共享密鑰K加密軟件描述文件M,并將加密文件C和部署包P和發(fā)送給TM.

流程4.CDC端驗證加密文件,執(zhí)行部署過程.

CDC端接收到CDS端發(fā)送的加密文件后,需要執(zhí)行解密文件、驗證部署包的一致性、安裝部署包等一系列操作,具體做法如下:

(1)TM 接收到部署包P和加密文件后,使用共享密鑰K解密該文件,得到軟件描述文件M:

(2)TM利用改進后的完整性度量算法計算部署包的完整性度量值,并與軟件描述文件中的記錄進行對比,如果一致,則進行后續(xù)操作,否則停止部署過程,Monitor 向CDS端反饋錯誤信息;

(3)TM解析部署包,驗證待部署軟件版本號是否與軟件描述文件相一致,如果一致,則進行后續(xù)操作,否則停止部署過程,Monitor模塊向CDS端反饋錯誤信息;

(4)TM解析軟件描述文件,驗證部署包內(nèi)是否存在完整的依賴文件,如果存在,則進行后續(xù)操作,否則停止部署過程,Monitor模塊向CDS端反饋錯誤信息;

(5)TM根據(jù)軟件依賴約束描述和平臺信息約束描述,調(diào)用SI模塊,進行軟件安裝工作,Monitor模塊監(jiān)控整個部署過程,并將部署結(jié)果通過CDC端發(fā)送給CDS端.

至此,一輪完整的軟件部署過程結(jié)束,其流程如圖4所示.在進行下一次部署工作之前,宿主機和目標機需要重新進行密鑰交換,協(xié)商出新的共享密鑰.

圖4 CTDMA方案設(shè)計流程圖

4 安全性證明和性能分析

4.1 安全性證明

宿主機和目標機暴露在開放的網(wǎng)絡(luò)環(huán)境下,其通信信息的安全性無法得到保證.CTDMA方案采用Diffie-Hellman密鑰交換算法,在每一輪會話過程中,共享密鑰K是保證通信安全性的關(guān)鍵.假定在宿主機H和目標機T所處的網(wǎng)絡(luò)環(huán)境中存在一個敵手A,A觀察到H和T進行了密鑰交換過程,并且期望得到它們協(xié)商出的共享密鑰K.由于Xh和Xt是會話雙方隨機選擇并且私有的,因此,A只能通過公開的參數(shù)q和α(q和α不一定需要公開,可通過修改算法由通信雙方協(xié)商決定),以及H和T的臨時公鑰Yh和Yt進行攻擊.由于如果A想獲得共享密鑰K,首先需要計算H的私鑰Xh.由于modq,Xh=dlogq,ɑ(Yh),A必須通過離散對數(shù)計算才能求得私鑰Xh,繼而求得共享密鑰.然而,Diffie-Hellman密鑰交換算法的安全性建立在以下事實之上:求素數(shù)的模素數(shù)冪運算相對容易,而計算離散對數(shù)卻非常困難;對于大素數(shù),求離散對數(shù)被認為是不可行的.因此,A無法通過求離散對數(shù)獲得共享密鑰K.

在集成部署過程中,散列算法的安全性較好,部署包數(shù)據(jù)發(fā)生微小的改變即能引起完整性度量值發(fā)生明顯的變化.因此采用散列算法可保證傳輸過程中部署包的完整性和一致性.此外,在集成部署之前,目標機端還需要驗證軟件版本號、依賴軟件的完整性以及平臺信息,進一步地提高了集成部署過程的可信性.

CTDMA方案與傳統(tǒng)的集成部署方式的安全性對比如表2所示.

4.2 性能分析

(1)理論分析

1)密鑰協(xié)商及通信信息加解密分析

在CTDMA方案中,Diffie-Hellman密鑰交換算法的計算周期主要分為兩個階段,一是共享密鑰的協(xié)商階段,二是部署雙方利用共享密鑰對通信信息進行加解密的階段.在實際處理過程中,這兩個階段均會帶來一定的計算開銷.

在密鑰協(xié)商階段,CDS端和CDC端需要計算各自的臨時公鑰和共享密鑰,由通用的運算公式K=αxmodq(0 ≤x≤q?1)可知:在此過程中,最大的計算開銷來源于大整數(shù)的冪運算和模運算.

在通信信息加解密階段,AES是一種對稱分組密碼算法,CDS端和CDC端可利用前一階段協(xié)商的共享密鑰作為對稱密鑰,通過AES 密碼算法對通信信息進行加解密.在有限域GF(28)上的多項式模運算是AES 密碼算法重要的數(shù)學基礎(chǔ),其中涉及到的運算包括字節(jié)替代正逆變換、列混淆正逆變換和輪密鑰擴展等,整套算法設(shè)計起來較為復(fù)雜.在本方案中,共享密鑰作為加解密的對稱密鑰,可擴展為128位,對應(yīng)的輪密鑰擴展為10輪.

2)完整性度量算法分析

CTDMA方案對于完整性度量散列算法的優(yōu)化主要在于將原算法的計算方式由串行計算改為了并行計算,可通過加速比衡量并行優(yōu)化帶來的性能變化.

根據(jù)Amdahl 定律,加速比的計算為:

其中,p為運算的線程數(shù),f為串行計算在整個計算過程中占的比重.

設(shè)系統(tǒng)I/O 速率為sr,sr=fs(m),計算速率為su,考慮算法并行部分訪存無依賴,由式(1)可推得并行優(yōu)化的完整性度量算法(以下簡稱為并行算法)加速比為:

考慮到通信、同步以及空閑等待時間等因素,設(shè)T0為并行算法的額外開銷時間,T為串行算法執(zhí)行總時間,并行算法的實際加速比為:

在并行算法中,Pr為Read線程數(shù),Pu為Update線程數(shù).

假設(shè)部署包大小為S,并行算法將其分塊處理后,單塊文件大小為m,Read線程耗時記為Tr,Update線程耗時記為Tu,串行算法總時間記為T,并行算法總時間記為Tp.并行算法的額外開銷記為T0.

計算公式如下:

3)自動集成部署能力分析

在CTDMA方案中,自動集成部署階段的一個周期包括軟件描述文件生成、軟件部署包集成以及部署包解壓安裝幾個部分.其中軟件部署包內(nèi)又包含待部署軟件、依賴的軟件和庫以及相應(yīng)的配置文件.因此,相對于單一的待部署軟件來講,其依賴的軟件和庫越多,軟件描述信息的結(jié)構(gòu)就越復(fù)雜,生成的軟件部署包就越大,部署過程耗時就越長.

其中,軟件描述文件生成和軟件部署包集成部分均為前期工作,對于同一批次的部署任務(wù)來講,前期工作只需要進行一次,便可以應(yīng)用在多個目標機客戶端上,同時,協(xié)同部署客戶端接收到服務(wù)器端發(fā)送的軟件描述文件和軟件部署包后,便可同時進行軟件部署工作.因此,待部署的目標機數(shù)量越多,整個部署任務(wù)的耗時就越短.

自動集成部署適用于大規(guī)模、復(fù)雜情況下的集成部署任務(wù).

(2)實驗結(jié)果

1)實驗平臺

本文的實驗方案主要針對Diffie-Hellman密鑰交換算法、AES 加解密算法、改進的完整性度量算法以及自動集成部署能力測試4部分,根據(jù)方案的特點設(shè)計實驗用例,并利用開源的安全加密軟件庫Openssl實現(xiàn)以上密碼算法的功能,并度量其計算性能.實驗平臺的軟硬件信息如表3所示.

表3 實驗環(huán)境

2)測試方案

① Diffie-Hellman密鑰交換算法的實現(xiàn)和性能分析

本方案利用Openssl 提供的接口實現(xiàn)了Diffie-Hellman密鑰交換算法的基本功能,包括部署雙方密鑰參數(shù)集合的生成、公私鑰對的生成以及共享密鑰的生成,其中,按照AES 密碼算法的標準(在部署雙方安全通信的過程中,共享密鑰將作為AES算法的私鑰使用),將共享密鑰擴展為128位.

在實驗平臺下,通過多次測量,每個階段的計算開銷如表4所示.

表4 Diffie-Hellman密鑰交換算法各階段耗時

通過表4可知,密鑰參數(shù)的生成階段耗時極小,幾乎可以忽略不計,主要的計算開銷在于公私鑰對和共享密鑰的生成部分,該部分需要進行冪運算和模運算,因此存在比較復(fù)雜的計算量,但是考慮到后續(xù)的實驗數(shù)據(jù),Diffie-Hellman密鑰交換算法的計算開銷只占整個部署過程的一小部分.

② AES密鑰算法的實現(xiàn)和性能分析

在本方案中,AES密鑰算法主要用于在部署雙方之間對通信信息進行加解密計算.通信信息主要包括軟件部署包和軟件描述文件,由于軟件描述文件和軟件部署包之間存在一致性,只需要對軟件描述文件進行加解密即可保證通信信息的安全性,并且也可以有效地提高加解密過程的計算效率.Openssl 提供的加解密接口AES_set_encrypt_key()、AES_set_decrypt_key()和AES_cbc_encrypt()可實現(xiàn)AES密鑰算法的基本功能.

在測試用例的設(shè)計過程中,設(shè)置密鑰長度為128位(16字節(jié)),相應(yīng)的密鑰擴展輪數(shù)為10輪.由于明文的分組長度為固定的128位,所以軟件描述文件中的數(shù)據(jù)越長,分組就越多,相應(yīng)的加解密復(fù)雜度就越高,耗時就越長.

本方案的測試用例以軟件描述文件的數(shù)據(jù)長度為測試變量,驗證數(shù)據(jù)長度大小對于通信信息加解密的計算開銷的影響.測試流程如下:

a.生成不同長度的軟件描述信息,依次寫入不同的文件中;

b.測試用例對不同的軟件描述文件進行加密操作,然后將密文信息依次寫入加密文件,統(tǒng)計執(zhí)行時間;

c.測試用例對不同的密文文件進行解密操作,然后依次還原軟件描述文件,統(tǒng)計執(zhí)行時間.

通過多次測量,計算開銷如表5所示.

表5 AES算法下不同大小的文件加解密耗時比較

通過表5可知:

a.在相同的數(shù)據(jù)長度下,AES測試用例的加解密耗時幾乎相同,這是因為AES密鑰算法的加解密過程幾乎是相同的,解密過程是加密過程的逆變換,測量數(shù)據(jù)符合實際情況;

b.隨著測試數(shù)據(jù)長度的增加,加解密的計算開銷幾乎呈指數(shù)型增長,這是由于明文和密文分組增多,加解密過程中的計算量增大導(dǎo)致的.

在實際應(yīng)用中,由于軟件部署包的復(fù)雜性不同,描述文件的大小范圍一般固定在1 KB到10 KB之間,在這個區(qū)間內(nèi),加解密的計算耗時主要控制在1000 μs 以下,與Diffie-Hellman密鑰交換算法的測試數(shù)據(jù)相差不大,僅占整個部署過程的一小部分.

③ 完整性度量算法的改進及性能分析

本方案采用SHA-1算法為實驗對象(SHA-1算法為一種常用的完整性度量算法),原算法記為算法1,采用串行處理的方式進行計算,改進算法記為算法2,采用并行方式進行計算,其實驗平臺軟硬件信息如表6所示.

表6 算法1和算法2 耗時比較(單位:μs)

算法2通過對算法1 源碼進行并行化處理以達到優(yōu)化計算效率的目的,分為訪存階段和度量運算階段兩個部分,訪存階段使用Read線程進行處理,計算階段使用Update線程進行處理.其中,m值的大小與同步開銷存在著直接的聯(lián)系,可影響并行計算的效率.由文獻[10]可得結(jié)論:當m值的大小與文件系統(tǒng)block 大小相同時,程序的讀寫效率最高,串行計算的耗時最小.因此,根據(jù)實驗環(huán)境,m值大小應(yīng)選擇4 KB,這樣既能占用較小的緩存,也能保證算法的性能.

在測試環(huán)境下,本方案主要從以下兩個方面進行性能測試:

a.在算法2中,以部署包大小為變量,測試系統(tǒng)訪存速率和度量算法運算速率之間的變化,并計算加速比;

b.以部署包大小為變量,測試算法1和算法2度量耗時的變化,并計算加速比.

在算法2中,圖5顯示了針對不同大小的部署包,訪存速率和算法運算速率的變化情況,根據(jù)式(4)、式(5)以及表中數(shù)據(jù)可知,su=2.048×108 (Byte/s),sr=f(m)2.048×109(Byte/s).根據(jù)式(2)可知,其理論加速比為S≈1.05.

結(jié)論:

a.在算法2中,訪存階段的速率和計算階段的速率波動很小,幾乎不隨部署包大小的改變而改變;

b.訪存階段的速率遠小于計算階段的速率,在程序設(shè)計過程中,應(yīng)盡量減少對同一緩沖區(qū)進行I/O操作.

圖5 訪存階段耗時與計算階段耗時

表6和圖6記錄了針對不同大小的部署包,算法1和算法2 消耗的總時間以及算法2產(chǎn)生的額外開銷,根據(jù)式(3)和式(6)可知,算法1和算法2的實際加速比是S≈1.01.

圖6 串行計算耗時與并行計算耗時

通過分析上述數(shù)據(jù)可知:

a.針對不同大小的部署包,算法2的耗時小于算法1.與算法1相比,算法2 利用并行運算實現(xiàn)了訪存的隱藏,因此提高了計算效率;

b.考慮到額外消耗的時間,理論加速比和實際加速比幾乎一致.由于實驗選擇了合理的分塊大小,所以通信、同步和空閑等待時間等因素帶來的額外開銷在整個計算過程中所占比例較小.

c.在一般的部署任務(wù)中,部署包大小范圍一般在100 MB左右,部署包越大,算法2 相較于算法1的效率提升就越明顯,減少的計算耗時可抵消部署雙方通信加解密帶來的計算開銷.

④ 自動集成部署能力分析

Cube-1.3是一款基于Linux操作系統(tǒng)的可信網(wǎng)絡(luò)連接軟件,在安裝過程中,需要依賴的軟件包括libtool、autoconf和automake,同時需要在配置3條環(huán)境變量.

本方案以Cube-1.3軟件的安裝部署為例,設(shè)計測試用例,模擬自動部署過程,并以目標機的軟件裝機量為實驗變量,分析自動集成部署和手動部署之間的差異.

在手動部署過程中,需要進行環(huán)境配置、依賴軟件安裝、待部署軟件安裝3部分.針對單個裝機量來講,環(huán)境配置平均需要30 s,依賴軟件安裝需要25 s,待部署軟件安裝需要10 s,一共需要65 s即可完成一臺的裝機量.按照以上時間計算,手動部署10臺目標機的時間是650 s.

在自動集成部署過程中,測試用例主要測試軟件部署包集成和軟件部署包解壓安裝兩個部分,軟件描述文件主要使用腳本替代.其中,軟件描述文件的生成大約需要60 s,軟件部署包集成工作大約需要28 s,軟件部署包解壓安裝需要5 s,單臺目標機客戶端的軟件自動部署時間一共大約需要93 s.由于軟件描述文件和軟件部署包的生成部分都是前期工作,因此,在部署多臺目標機客戶端的過程中不需要重復(fù)生成,只需要通過網(wǎng)絡(luò)傳輸給相應(yīng)客戶端即可.按照單臺目標機自動集成部署的時間計算,部署10臺目標機的時間為:軟件描述文件生成60 s+軟件部署包集成28 s+軟件部署包解壓安裝8 s (10臺目標機同步自動安裝,由于網(wǎng)絡(luò)傳輸和目標機的差異性,最終全部安裝結(jié)束的時間具有差異性),一共約需要98 s.

通過分析上述數(shù)據(jù)可知:

a.自動集成部署需要進行前期準備工作,耗時較長,在軟件部署規(guī)模較小和復(fù)雜度較低的情況下,不如手動部署配置靈活,速度快;

b.在軟件規(guī)模大、結(jié)構(gòu)復(fù)雜的情況下,自動集成部署優(yōu)勢明顯,并且由于實現(xiàn)了標準化部署,出錯概率較低,后期維護成本小.

(3)實驗總結(jié)

1)相較于整個部署過程,Diffie-Hellman密鑰交換算法和AES 加解密算法帶來的計算開銷所占比重較小,但是對于通信信息的安全性提升很大;

2)關(guān)于軟件部署包的度量,本方案利用硬件環(huán)境多核多線程的特點,對完整性度量算法進行了并行化處理,部署包越大,線程數(shù)越多,計算效率的提升就越明顯,可有效地抵消方案中部分安全設(shè)計帶來的計算開銷;

3)在目標機規(guī)模大,任務(wù)復(fù)雜的情況下,采用自動集成部署的設(shè)計方案對于部署效率提升顯著.

5 結(jié)束語

在分布式協(xié)同開發(fā)環(huán)境下,軟件規(guī)模越來越大,其復(fù)雜性也越來越高,針對現(xiàn)有的軟件集成部署方法缺乏安全機制以及工作效率較低的問題,本文提出了一種安全高效的解決方案.該方案利用Diffie-Hellman密鑰交換算法為部署雙方創(chuàng)建安全關(guān)聯(lián),通過可部署軟件描述方法為待部署軟件建立規(guī)范化的軟件描述,并且改進完整性度量算法,進一步提高了軟件的部署效率.最后,本文通過安全性分析和性能測試實驗,說明了該方案的研究價值.

在后續(xù)研究過程中,本方案還需改善以下兩點:1)引入公鑰證書和數(shù)字簽名等密碼學機制,進一步提高本方案的安全性;2)本方案提供的集成部署方法還處于模型階段,后續(xù)過程中可在Eclipse、QtCreator 等開放式平臺的基礎(chǔ)上,實現(xiàn)部署過程的圖形化、智能化,構(gòu)建一套界面友好、使用方便的集成開發(fā)環(huán)境.