0 引言

    網(wǎng)絡(luò)的出現(xiàn)，方便了信息的流動．降低了人與人之間，以及企業(yè)之間信息流動的成本。為了充分發(fā)揮網(wǎng)絡(luò)在信息交互過程中的作用，就需要在網(wǎng)絡(luò)基礎(chǔ)架構(gòu)之上，構(gòu)建各式各樣的網(wǎng)絡(luò)服務(wù)，以支撐日常的應(yīng)用。目前各式各樣的網(wǎng)絡(luò)應(yīng)用隨處可見，但是多為封閉的系統(tǒng)．而為了更好的支持各種應(yīng)用場景．經(jīng)常需要對多個系統(tǒng)進(jìn)行集成，在多個服務(wù)之間進(jìn)行數(shù)據(jù)交換，協(xié)作完成共同的任務(wù)。Web Service正是為了處理這一問題而提出的構(gòu)建在現(xiàn)有網(wǎng)絡(luò)標(biāo)準(zhǔn)之上的、松耦合、跨平臺、跨語言的數(shù)據(jù)交換和通信的標(biāo)準(zhǔn)方法。

    Web Service系統(tǒng)利用互聯(lián)網(wǎng)為用戶提供服務(wù)，但是其關(guān)注與構(gòu)建系統(tǒng)之間通信的協(xié)議，專注于數(shù)據(jù)描述(XML)和交換(SOAP)，以及服務(wù)的描述(WSDL)與發(fā)布(UDDI)，而對安全性的支持較為欠缺，使軟件處于巨大的風(fēng)險(xiǎn)之中，需要在應(yīng)用中加以解決。

1 Web Service安全問題描述

    在日常應(yīng)用中，Web Service的安全威脅主要來自以下幾方面：

    (1)數(shù)據(jù)的保密性無法保證

    在網(wǎng)絡(luò)安全中，要求信息不能夠泄漏給未經(jīng)授權(quán)的用戶及惡意訪問者，而Web Service運(yùn)行在Internet之上，利用XML定義數(shù)據(jù)交換的格式，并利用SOAP進(jìn)行數(shù)據(jù)交換．整個過程都是通過網(wǎng)絡(luò)明文進(jìn)行傳輸，容易被惡意用戶監(jiān)聽和竊取。另外，由于Web Service的接口描述暴露在網(wǎng)絡(luò)之上，也存在被惡意用戶惡意調(diào)用的可能。

    (2)數(shù)據(jù)的完整性無法保證

    信息的完整性．要確保信息不會被未被授權(quán)用戶修改，確保信息在存儲、傳輸過程中不被修改、偽造和丟棄。而Web Service數(shù)據(jù)交換過程采用明文傳輸，該特性使得數(shù)據(jù)的完整性無法保證，能夠被惡意用戶修改，或偽造。

    另外，在Web Service中沒有提供相關(guān)的方法，對用戶的身份進(jìn)行必要的校驗(yàn)，也缺乏必要的權(quán)限控制，容易造成未授權(quán)操作，從而泄漏系統(tǒng)的信息，甚至危及系統(tǒng)的安全。

    (3)缺乏必要的身份驗(yàn)證機(jī)制

    Web Services并未定義相關(guān)的方法，對調(diào)用方以及服務(wù)提供方的身份進(jìn)行必要的確認(rèn)，從而無法保證Web服務(wù)的合法性，危及系統(tǒng)的安全。

    (4)缺乏可擴(kuò)展可靈活部署的加密方法

    在日常的應(yīng)用中．通常采用SSL協(xié)議，對Web Service數(shù)據(jù)傳輸過程進(jìn)行加密和保護(hù)，但是利用SSL進(jìn)行加密操作時，會頻繁的進(jìn)行加密解密操作，從而影響系統(tǒng)的通信性能，降低系統(tǒng)的性能。該問題在PDM系統(tǒng)中表現(xiàn)尤為突出。PDM系統(tǒng)中傳輸?shù)亩酁轶w積龐大的工程設(shè)計(jì)文件，采用SSL的方法，會對系統(tǒng)的性能帶來極大的影響。而在處理用戶登錄信息、密鑰傳輸?shù)葐栴}時，SSL又是一個成熟的方法。因此在應(yīng)用中需要更具實(shí)際情況，靈活的選擇加密方法。

    針對以上問題．在綜合考慮了可使用性、性能、私密性等因素后，設(shè)計(jì)和實(shí)現(xiàn)了一套傳輸層加密方法，根據(jù)PDM系統(tǒng)的特點(diǎn)，針對不同的需要，采用不同的方法對數(shù)據(jù)進(jìn)行加密操作，并應(yīng)用在了實(shí)際的PDM系統(tǒng)中。

2 傳輸層加密方法

    2.1 概述

    在PDM（Product Data Management，產(chǎn)品數(shù)據(jù)管理）系統(tǒng)中，主要需要面對兩種數(shù)據(jù)。一種是設(shè)計(jì)的文檔、圖紙等二進(jìn)制數(shù)據(jù)信息，這些數(shù)據(jù)數(shù)據(jù)量大，變化較快，并且這些數(shù)據(jù)往往具有一定的時間效應(yīng)．只需要保證一定的時效范圍內(nèi)不被破解．無法獲取即可，因此，針對這部分?jǐn)?shù)據(jù)，可以采用簡單的加密方式，確保在可容忍的時間范圍內(nèi)，無法被破解即可。因此在傳送大數(shù)量信息時，采用了RC2加密算法進(jìn)行加密操作．其特點(diǎn)是加解密速度快，而且形成的加密文件體積并不會增大。在加密的過程中，如果傳輸?shù)氖潜容^大的圖紙類文件，要先進(jìn)行壓縮。如果是數(shù)據(jù)庫的表文件，則轉(zhuǎn)換成XML文件，然后再進(jìn)行加密。

    除文檔數(shù)據(jù)外，主要為系統(tǒng)內(nèi)部的通信協(xié)作及信息交換，相比設(shè)計(jì)文檔數(shù)據(jù)，這部分?jǐn)?shù)據(jù)數(shù)據(jù)量小，但經(jīng)常包含較為敏感的用戶信息，如密鑰信息、權(quán)限信息等，針對這部分?jǐn)?shù)據(jù)，需要進(jìn)行較為嚴(yán)格的加密，確保訪問時經(jīng)過授權(quán)，且無法被監(jiān)聽與破解。兼顧到身份驗(yàn)證的需要，這部分基于開源的CA中心，對用戶證書進(jìn)行發(fā)放和管理。在數(shù)據(jù)通信過程中，利用證書對交換的信息進(jìn)行加密操作，從而保證數(shù)據(jù)的完整性。

    傳輸層加密的體系結(jié)構(gòu)如圖1所示。

    圖1 傳輸層加解密體系結(jié)構(gòu)

    圖中，業(yè)務(wù)邏輯為實(shí)際的應(yīng)用邏輯，在傳輸過程中，會調(diào)用下層的安全服務(wù)，對傳輸數(shù)據(jù)進(jìn)行處理，確保服務(wù)的安全性。

    安全服務(wù)模塊為系統(tǒng)提供加密解密服務(wù)及數(shù)字簽名的校驗(yàn)，向應(yīng)用的業(yè)務(wù)邏輯提供安全服務(wù)。安全模塊具備RSA、RC2和M123三套數(shù)據(jù)加解密方法組。其中，M123加解密方法是一個自定義的對稱密鑰加密算法，該算法利用三個數(shù)字(m1，m2，m3)作為密鑰，利用自定義的加密算法，根據(jù)(m1，m2，m3)生成相應(yīng)的密文，同時在每次加密后，利用Feistel結(jié)構(gòu)，對密鑰進(jìn)行混淆和輪替。M123加密方法主要用于對交換的密鑰進(jìn)行加密，增加密鑰交換的安全性。

    密鑰及證書管理模塊主要負(fù)責(zé)處理證書的請求，密鑰交換。對稱密鑰管理模塊主要用于對稱密鑰的生成及管理，證書文件主要用于獲取本身私鑰及向CA請求上層安全模塊需要的證書信息。

    2.2 服務(wù)器端密鑰生成及交換

    服務(wù)端在服務(wù)啟動后，會隨機(jī)生成RC2加密密鑰和M123加密密鑰。在密鑰生成過程中，為了避免偽隨機(jī)帶來的問題，會利用隨機(jī)數(shù)、機(jī)器碼、機(jī)器時鐘、加密算法的名稱及當(dāng)前時間綜合生成源串，對該源串利用MD5算法生成摘要后，作為密鑰。

    在每個用戶登錄后，服務(wù)端向證書中心請求該用戶的證書信息，利用證書對RC2加密密鑰和M123加密密鑰進(jìn)行加密，并對加密后的數(shù)據(jù)進(jìn)行簽名，后發(fā)送給用戶，用于用戶的密鑰交換。

    服務(wù)器端的密鑰生成及交換過程如圖2所示。

    圖2 服務(wù)器端的密鑰生成及交換過程

    為了提高系統(tǒng)的安全性，對于服務(wù)器端的對稱加密密鑰均設(shè)置了超時時間，當(dāng)超時后，服務(wù)器端會重新生成新的密鑰。

    2.3 客戶端密鑰請求及交換流程

    客戶端在登錄后．會接收服務(wù)器端發(fā)送的RC2密鑰和M123密鑰，同時在每次請求是隨機(jī)生成RC2密鑰�？蛻舳穗S機(jī)數(shù)生成的過程中的源碼，除了與服務(wù)器端相同的因素外，還增加了用戶名、用戶密碼的md5值及客戶端ip等信息，以增大隨機(jī)性及源碼的復(fù)雜度。

    客戶端密鑰交換的過程中，會利用服務(wù)端的RC2密鑰和M123密鑰對生成的RC2密鑰進(jìn)行加密，并做數(shù)字簽名后，附加在請求中，發(fā)送給服務(wù)端。在此過程中，并未利用服務(wù)端證書對加密后的密鑰信息進(jìn)行再次加密，是為了避免頻繁的密鑰交換給服務(wù)器帶來過大的壓力。客戶端的密鑰生成及交換過程如圖3所示。

    圖3 客戶端的密鑰生成及交換過程

    同樣，為了保證安全性，客戶端的密鑰也規(guī)定了一定的有效時間，會定時進(jìn)行更新�？蛻舳说拿荑�用于加密客戶端與服務(wù)器間的每次請求。

    2.4 整體流程分析

    下面將對本方法的整體流程其進(jìn)行詳細(xì)描述。

    (1)服務(wù)端生成加密密鑰

    服務(wù)端啟動服務(wù)的時，會自動生成RC2密鑰及M123密鑰。

    (2)客戶登錄并獲取服務(wù)器端加密密鑰

    客戶在登錄時，會對登錄密碼進(jìn)行摘要操作，并利用服務(wù)器端證書文件加密密鑰信息，傳輸給服務(wù)端，服務(wù)端對解密并驗(yàn)證密碼通過后，服務(wù)端將獲取該用戶的證書文件，加密密鑰傳遞給客戶方。

    (3)客戶端請求業(yè)務(wù)處理

    當(dāng)客戶在一段時間內(nèi)，第一次發(fā)起請求時，客戶端生成隨機(jī)的RC2密鑰，利用該RC2密鑰對請求進(jìn)行加密，同時利用服務(wù)端的RC2密鑰及M123密鑰對客戶端的RC2密鑰進(jìn)行加密，附加在請求信息中發(fā)送給服務(wù)方。此過程中，需要對信息整體添加數(shù)字簽名。

    (4)服務(wù)端響應(yīng)請求

    服務(wù)方收到請求后，利用自身保留的RC2密鑰及M123密鑰，解密報(bào)文巾的密鑰信息，獲取客戶端的RC2密鑰，利用客戶湍的RC2密鑰解密請求內(nèi)容，并進(jìn)行處理。完成處理邏輯后，服務(wù)端利用客戶端的RC2密鑰加密結(jié)果，并添加簽名信息后，將數(shù)據(jù)返回客戶端。

3 總結(jié)

    利用該方案，減少了加密及解密過程中的數(shù)據(jù)交換，同時確保了關(guān)鍵信息的保密性、完整性，確保了web Service整個請求過程中的安全性。選取該方案的主要優(yōu)勢在于：

    (1)性能好：在用戶登錄時，以及小數(shù)據(jù)量的交換時，使用RSA加密，整體速度不受影響，經(jīng)測試能達(dá)到客戶要求。

    (2)安全性好：由于密鑰具有一定的時效性，攻擊者即使截獲了一個文件并成功解密，也無法利用一直的密鑰，解密以后數(shù)據(jù)。

    (3)加密流程是自定義：如果不了解具體項(xiàng)目傳輸層加密的思想，即使截獲了數(shù)據(jù)，也很難利用通常的思維進(jìn)行解密，加大了解密的難度。

核心關(guān)注：拓步ERP系統(tǒng)平臺是覆蓋了眾多的業(yè)務(wù)領(lǐng)域、行業(yè)應(yīng)用，蘊(yùn)涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務(wù)管理理念，功能涉及供應(yīng)鏈、成本、制造、CRM、HR等眾多業(yè)務(wù)領(lǐng)域的管理，全面涵蓋了企業(yè)關(guān)注ERP管理系統(tǒng)的核心領(lǐng)域，是眾多中小企業(yè)信息化建設(shè)首選的ERP管理軟件信賴品牌。

轉(zhuǎn)載請注明出處：拓步ERP資訊網(wǎng)http://www.ezxoed.cn/

本文標(biāo)題：基于Web Service的PDM傳輸層加解密方案

本文網(wǎng)址：http://www.ezxoed.cn/html/solutions/1401937254.html