時(shí)間：2022-10-04 18:05:56
緒論：在尋找寫作靈感嗎？愛發(fā)表網(wǎng)為您精選了8篇ssl協(xié)議，愿這些內(nèi)容能夠啟迪您的思維，激發(fā)您的創(chuàng)作熱情，歡迎您的閱讀與分享！
[關(guān)鍵詞] 網(wǎng)絡(luò)安全 VPN ssl 體系結(jié)構(gòu) 工作模式
VPN（Virtual Personal Network，虛擬專用網(wǎng)）是通過一個(gè)私有的通道將遠(yuǎn)程用戶、公司分支機(jī)構(gòu)、公司業(yè)務(wù)伙伴等與公司的企業(yè)網(wǎng)連接起來，構(gòu)成一個(gè)擴(kuò)展的公司企業(yè)網(wǎng),通過在公共網(wǎng)絡(luò)中建立專用網(wǎng)絡(luò)，數(shù)據(jù)通過安全的“加密通道”在公共網(wǎng)絡(luò)中傳播。SSL VPN是一種新的VPN的實(shí)現(xiàn)方法，是可靠安全地構(gòu)建VPN的一種模式。
一、SSL協(xié)議
1.SSL概述
SSL（Secure Socket Layer,安全套接層）協(xié)議是 Netscape 公司于1994年提出的一個(gè)網(wǎng)絡(luò)安全通信協(xié)議，是一種在兩臺(tái)機(jī)器之間提供安全通道的協(xié)議。它具有保護(hù)傳輸數(shù)據(jù)，以及識(shí)別通信機(jī)器的功能。SSL最初是通過加密HTTP連接為Web瀏覽器提供安全而引入的。
SSL在TCP上提供一種通用的通道安全機(jī)制，任何可以在TCP上承載的協(xié)議都能夠使用SSL加以保護(hù)。在TCP或IP四層協(xié)議族中，SSL協(xié)議位于傳輸層與應(yīng)用層之間，基于可靠傳輸協(xié)議TCP，服務(wù)于各種應(yīng)用層協(xié)議，如HTTP、POP、TELNET等，它們?cè)赟SL協(xié)議上運(yùn)行分別被稱作HTTPS、POPS、TELNETS協(xié)議等，分別對(duì)應(yīng)的端口號(hào)為443、995、992等。
圖1 SSL協(xié)議結(jié)構(gòu)圖
2.SSL體系結(jié)構(gòu)
SSL協(xié)議在結(jié)構(gòu)上分為兩個(gè)層次：底層為記錄層協(xié)議（Record Protocol），負(fù)責(zé)封裝高層協(xié)議（包括握手協(xié)議）的數(shù)據(jù)，保證SSL連接的數(shù)據(jù)保密性和完整性；高層為握手層，由四個(gè)并行的協(xié)議構(gòu)成：握手協(xié)議（Handshake Protocol）、修改密碼參數(shù)協(xié)議（Change Cipher Spec Protocol）、報(bào)警協(xié)議（Alert Protocol）、應(yīng)用數(shù)據(jù)協(xié)議（Application data Protocol），高層協(xié)議需要記錄層協(xié)議支持，其中握手協(xié)議與其他的高層協(xié)議不同，主要負(fù)責(zé)在交換應(yīng)用層數(shù)據(jù)之前進(jìn)行協(xié)商加密算法與密鑰，其他高層協(xié)議屬于應(yīng)用開發(fā)的范疇，而要得到握手協(xié)議的支持，而握手協(xié)議則是SSL底層實(shí)現(xiàn)必須具有的功能，因?yàn)橛涗泴訁f(xié)議的完成也由它來保證。
二、基于SSL協(xié)議的VPN技術(shù)研究
1.SSLVPN概念
SSL VPN是指一種基于數(shù)據(jù)包封裝技術(shù)的，利用SSL或TLS協(xié)議結(jié)合強(qiáng)加密算法和身份認(rèn)證技術(shù)的，可靠安全地構(gòu)建VPN的一種方法。它作為一種新的VPN的實(shí)現(xiàn)方法，SSL VPN可以用來構(gòu)建外聯(lián)網(wǎng)、內(nèi)聯(lián)網(wǎng)和遠(yuǎn)程接入訪問。它通過數(shù)據(jù)包封裝的隧道技術(shù)來實(shí)現(xiàn)虛擬專用網(wǎng)的私有性，通過PKI技術(shù)和密碼學(xué)技術(shù)來鑒別通信雙方的身份和確保傳輸數(shù)據(jù)的安全。
2.SSL VPN的工作模式
(1)基于Web模式的SSL VPN系統(tǒng)
客戶端使用瀏覽器通過SSLVPN 服務(wù)器來訪問企業(yè)局域網(wǎng)的內(nèi)部資源。SSLVPN 服務(wù)器相當(dāng)于一個(gè)數(shù)據(jù)中轉(zhuǎn)站，Web瀏覽器對(duì)WWW服務(wù)器的訪問經(jīng)過SSL VPN服務(wù)器的處理（解密、身份鑒別、訪問控制）后轉(zhuǎn)發(fā)給WWW服務(wù)器，從WWW服務(wù)器發(fā)往Web瀏覽器的數(shù)據(jù)經(jīng)過SSL VPN服務(wù)器處理（過濾、加密）后送到Web瀏覽器。
圖2 基于Web模式的SSL VPN系統(tǒng)
(2)基于客戶模式的SSL VPN
用戶在客戶端安裝一個(gè)SSL VPN客戶端程序，當(dāng)客戶端訪問企業(yè)內(nèi)部的應(yīng)用服務(wù)器時(shí)，需要經(jīng)過SSL VPN客戶端程序和SSL VPN服務(wù)器之間的保密傳輸后才能到達(dá)。從而在SSLVPN客戶端和 SSLVPN服務(wù)器之間，由SSL協(xié)議構(gòu)建一條安全通道，保護(hù)客戶端與SSLVPN服務(wù)器之間的數(shù)據(jù)傳輸。此時(shí)，SSLVPN服務(wù)器充當(dāng)服務(wù)器的角色，SSL VPN客戶端充當(dāng)客戶端的角色。
圖3 基于客戶端模式的SSL VPN系統(tǒng)
(3)局域網(wǎng)到局域網(wǎng)模式的SSL VPN系統(tǒng)
在網(wǎng)絡(luò)邊緣都安裝和配置了SSLVPN服務(wù)器。當(dāng)一個(gè)局域網(wǎng)內(nèi)的終端要訪問遠(yuǎn)程網(wǎng)絡(luò)內(nèi)的應(yīng)用服務(wù)器時(shí)，需要經(jīng)過兩個(gè)SSL VPN服務(wù)器之間的保密傳輸后才能到達(dá)。從而在兩個(gè)SSLVPN服務(wù)器之間，由SSL協(xié)議構(gòu)建一條安全通道，保護(hù)局域網(wǎng)之間的數(shù)據(jù)傳輸。此時(shí)，SSL VPN服務(wù)器充當(dāng)安全網(wǎng)關(guān)的角色。
圖4 局域網(wǎng)到局域網(wǎng)模式的SSL VPN系統(tǒng)
參考文獻(xiàn):
[1]徐家臻陳莘萌:基于IPSec與基于SSL的VPN的比較與分析[J].計(jì)算機(jī)工程與設(shè)計(jì),2004,(04)
關(guān)鍵詞：SSL協(xié)議；安全套接層；安全性
中圖分類號(hào)：TP393文獻(xiàn)標(biāo)識(shí)碼：A文章編號(hào)：1009-3044(2012)12-2726-03
當(dāng)前，互聯(lián)網(wǎng)技術(shù)的不斷更新和發(fā)展，給我們的生活帶來了很多便利。但與此同時(shí)也帶來了很多網(wǎng)絡(luò)信息安全性的威脅。隨著信息網(wǎng)絡(luò)的發(fā)展，信息安全越來越引起人們的關(guān)注。如當(dāng)今流行的電子商務(wù)、電子政務(wù)、電子郵件等，除了其業(yè)務(wù)本身，人們更加關(guān)心的是其安全性。這樣我們需要保證信息的保密性、完整性，通信雙方的認(rèn)證等，這正是過去網(wǎng)絡(luò)所缺乏。這就有了安全套接層（Security Socket Layer Protocol，簡(jiǎn)稱SSL協(xié)議）。它是現(xiàn)在互聯(lián)網(wǎng)上保證信息安全傳輸?shù)囊环N網(wǎng)絡(luò)協(xié)議。
1概述
SSL是由Netscape公司設(shè)計(jì)的一種開放性協(xié)議，利用數(shù)據(jù)加密技術(shù)，保證數(shù)據(jù)在公開網(wǎng)絡(luò)中傳輸不被截取及竊聽修改，以保障互聯(lián)網(wǎng)信息的安全傳輸。SSL協(xié)議是介于傳輸層和應(yīng)用層之間的，為應(yīng)用層提供數(shù)據(jù)保密服務(wù)。其優(yōu)勢(shì)在于它與應(yīng)用層協(xié)議獨(dú)立無關(guān)。這樣SSL協(xié)議可以透明的為應(yīng)用層協(xié)議提供服務(wù)。應(yīng)用層協(xié)議在通信之前，SSL協(xié)議就將傳輸?shù)臄?shù)據(jù)加密、完成通信密鑰的協(xié)商，以及服務(wù)器認(rèn)證工作等。之后，應(yīng)用層所傳輸?shù)臄?shù)據(jù)都是被加密的，從而保證通信的安全性。SSL協(xié)議目前已經(jīng)有2.0和3.0版本?，F(xiàn)在它已被廣泛地用于Web瀏覽器與服務(wù)器之間的身份認(rèn)證和加密數(shù)據(jù)傳輸。
SSL協(xié)議提供的安全信道有以下三個(gè)特性。
1）私密性：從應(yīng)用層經(jīng)過SSL協(xié)議的數(shù)據(jù)，所有的消息都是被加密后才到傳輸層的。
2）確認(rèn)性：服務(wù)器端是被認(rèn)證的。
3）可靠性：所有傳輸?shù)南⒍际墙?jīng)過完整性檢查的。
2 SSL協(xié)議結(jié)構(gòu)
SSL協(xié)議的目標(biāo)在于在TCP的基礎(chǔ)上提供安全可靠的傳輸服務(wù)。在SSL的體系結(jié)構(gòu)中包括了SSL握手協(xié)議層和SSL記錄協(xié)議層兩個(gè)協(xié)議子層。這兩大協(xié)議完成了SSL的大部分工作。SSL握手協(xié)議層建立在SSL記錄協(xié)議層之上。建立在SSL記錄協(xié)議層上的還有密碼參數(shù)修改協(xié)議、報(bào)警協(xié)議、應(yīng)用數(shù)據(jù)協(xié)議等子協(xié)議。
圖1 SSL體系結(jié)構(gòu)圖
2.1 SSL記錄協(xié)議
SSL記錄協(xié)議限定了所有要傳輸?shù)臄?shù)據(jù)的打包，所有的傳輸數(shù)據(jù)都被封裝在記錄中。它提供了通信、身份認(rèn)證功能。由上層傳來的數(shù)據(jù)信息，將在記錄協(xié)議層，劃分?jǐn)?shù)據(jù)分段。依據(jù)握手協(xié)議中協(xié)商的加密算法，給分段的數(shù)據(jù)壓縮、計(jì)算MAC值、對(duì)數(shù)據(jù)加密處理，將數(shù)據(jù)變成記錄。添上記錄頭后，傳遞到下層的TCP協(xié)議。
SSL記錄頭格式
SSL記錄頭包括記錄頭長(zhǎng)度、記錄數(shù)據(jù)長(zhǎng)度的信息，及記錄數(shù)據(jù)中是否填充數(shù)據(jù)。當(dāng)最高位為1時(shí)，則不含有填充數(shù)據(jù)，記錄頭為兩字節(jié)，記錄數(shù)據(jù)最大長(zhǎng)度為32767字節(jié)；當(dāng)最高位為0時(shí)，則含有填充數(shù)據(jù)，記錄頭為三個(gè)字節(jié)，記錄數(shù)據(jù)的最大長(zhǎng)度為16383字節(jié)。當(dāng)記錄頭長(zhǎng)度是為三個(gè)字節(jié)時(shí)，次高位有特殊的含義。當(dāng)次高位為1時(shí)，標(biāo)識(shí)所傳輸?shù)挠涗浭瞧胀ǖ臄?shù)據(jù)記錄；當(dāng)次高位為0時(shí)，標(biāo)識(shí)所傳輸?shù)挠涗浭前踩瞻子涗洠ū槐Ａ粲糜趯韰f(xié)議的擴(kuò)展）。
SSL記錄數(shù)據(jù)格式
SSL的記錄數(shù)據(jù)包含三個(gè)部分：MAC數(shù)據(jù)、實(shí)際數(shù)據(jù)和填充數(shù)據(jù)（若是需要的話）。MAC數(shù)據(jù)為密鑰，實(shí)際數(shù)據(jù)，填充數(shù)據(jù)，序號(hào)的拼接后的散列值。用于檢查數(shù)據(jù)的完整性。
2.2 SSL握手協(xié)議層
SSL握手協(xié)議層包括握手協(xié)議（Handshake Protocol）、密碼參數(shù)修改協(xié)議（SSL Change Cipher Spec Protocol）、應(yīng)用數(shù)據(jù)協(xié)議（Application Data Protocol）和報(bào)警協(xié)議（Alert Protocol）。握手協(xié)議主要負(fù)責(zé)協(xié)商客戶端和服務(wù)器端所有使用的參數(shù)，包括采用協(xié)議版本、加密算法、密鑰等；建立獨(dú)立的安全會(huì)話連接，認(rèn)證雙方的身份。密碼參數(shù)修改協(xié)議主要負(fù)責(zé)協(xié)商雙方修改密碼參數(shù)，并指示記錄層把即將讀/寫狀態(tài)編程當(dāng)前讀/寫狀態(tài)?？蛻舳撕头?wù)器均可發(fā)送此類消息，通知對(duì)方記錄將使用新的協(xié)商密碼說明和密鑰。報(bào)警協(xié)議主要是負(fù)責(zé)通知對(duì)方警告信息。例如關(guān)閉通知、錯(cuò)誤記錄、解壓失敗、握手失敗、無證書、錯(cuò)誤證書等等。應(yīng)用數(shù)據(jù)協(xié)議主要負(fù)責(zé)將應(yīng)用數(shù)據(jù)直接傳遞給記錄協(xié)議。
3 SSL協(xié)議工作過程
1）由客戶端向服務(wù)器端發(fā)送“ClientHello”信息，以便開始一個(gè)新的安全對(duì)話連接。信息中將表明客戶端密碼能力。例如SSL版本，使用的加密算法、簽名算法、密鑰交換算法、可接受的壓縮算法等。
2）由服務(wù)器回應(yīng)客戶端發(fā)送“SeverHello”信息（如果可以接受其回應(yīng)的話，否則握手失敗。注：客戶端和服務(wù)器端必須要至少支持一個(gè)公共密碼對(duì)，否則握手將會(huì)失?。??！癝erverHello”消息將告知服務(wù)器的相關(guān)安全參數(shù)。
3）由服務(wù)器向客戶端發(fā)送它使用的證書和密鑰交換信息。若服務(wù)器端需要對(duì)客戶端認(rèn)證，則還會(huì)向客戶端發(fā)出“數(shù)字證書”的請(qǐng)求消息。
4）服務(wù)器發(fā)出“ServerHello Done”消息并等待客戶端響應(yīng)。
5）客戶端收到了“ServerHello Done”以后，將對(duì)服務(wù)器發(fā)送過來的數(shù)字證書驗(yàn)證，并檢查服務(wù)端的安全參數(shù)是否可以接受。如果服務(wù)器端需要客戶端的數(shù)字證書的話，則客戶端將要發(fā)送它的數(shù)字證書。如果客戶端沒有數(shù)字證書可有，則發(fā)送一個(gè)警告信息表明沒有數(shù)字證書，但將會(huì)導(dǎo)致本次握手失敗（如果客戶端數(shù)字證書認(rèn)證是強(qiáng)制性的話）。
6）客戶端發(fā)送“客戶端密鑰交換”消息。消息中包含有“預(yù)-主密鑰”和消息認(rèn)證代碼( MAC )密鑰（消息使用了服務(wù)器端公鑰加密，故此消息只有服務(wù)器可以用私鑰解密）。
7）客戶端將計(jì)算出“主密鑰”。然后，客戶端發(fā)“更改密碼規(guī)范”消息給服務(wù)器，以確定本次傳輸使用的加密套件和密鑰。
8）服務(wù)器確定了本次傳輸使用的加密套件和密鑰。完成本次握手。
9）此后的傳輸?shù)臄?shù)據(jù)都將加密后才傳輸。
圖2 SSL協(xié)議工作過程
（標(biāo)有括號(hào)的表示服務(wù)器需要驗(yàn)證客戶端的情況）
4 SSL安全性分析
1）算法安全性。SSL協(xié)議v2/v3均支持的算法有RC2、RC4、IDEA、DES、3DES等。認(rèn)證算法采用X.509電子證書標(biāo)準(zhǔn)，使用RSA算法進(jìn)行數(shù)字簽名。SSL協(xié)議通過使用數(shù)字證書來完成客戶端和服務(wù)器端之間的身份驗(yàn)證。通過SSL握手，雙方使用非對(duì)稱密碼體制協(xié)商并確定本次對(duì)話所要使用的加密算法和會(huì)話密鑰。這樣不僅保證了會(huì)話密鑰協(xié)商過程的安全性，而且又克服了非對(duì)稱密碼加密速度慢的缺陷。SSL協(xié)議所提供的混合密碼體制，可使SSL使用的加密算法和會(huì)話密鑰適時(shí)的變更。此外，協(xié)議還提供完整性的檢查，保證數(shù)據(jù)不被篡改。
2）抵抗重放攻擊。SSL協(xié)議使用了序列號(hào)，序列號(hào)經(jīng)加密后傳輸。在每一次握手都使用了一個(gè)隨機(jī)數(shù)來標(biāo)示本次握手，從而阻止了重放攻擊。
5 SSL存在的問題和改進(jìn)
1）加密強(qiáng)度問題。由于美國(guó)對(duì)加密技術(shù)出口的限制，SSL支持的對(duì)稱加密算法受到了影響。如密鑰長(zhǎng)度朝超過40位的對(duì)稱加密算法RC4、DES等不能用于SSL的數(shù)據(jù)加密。一般的，使用同一加密算法，密鑰位數(shù)越高其安全性越強(qiáng)。盡管SSL所支持的加密算法的安全強(qiáng)度都比較高，但出口到我國(guó)的僅支持低位密鑰算法，削弱了加密算法的安全性。此外加密數(shù)據(jù)的安全性還取決于密碼管理的安全性。同樣的，美國(guó)對(duì)密碼技術(shù)出口的限制，如在SSL規(guī)范中限定RSA算法和DH算法采用512位的密鑰。非對(duì)稱算法如果要保證其安全性，一般是需要1024位以上的。這樣使得密鑰交換的安全性得不到保證。所以，首先在算法選擇上，應(yīng)當(dāng)把一些不安全的算法如DES等移去。在實(shí)現(xiàn)中選擇對(duì)稱加密算法3DES、IDEA、AES等。在實(shí)現(xiàn)SSL時(shí)，都應(yīng)該限定交換密鑰長(zhǎng)度必須為1024位或更多位?；蛘呖梢赃x用橢圓曲線算法。這樣不僅可以密鑰比較短，而且處理速度比較快。
2）簽名問題。SSL協(xié)議不能數(shù)字簽名。雖然SSL可很好保證數(shù)據(jù)傳輸?shù)臋C(jī)密性和完整性，但缺乏數(shù)字簽名是其在電子商務(wù)應(yīng)用中一大缺憾。而事實(shí)上，SSL本身就有對(duì)消息進(jìn)行數(shù)字簽名和驗(yàn)證的潛力。因?yàn)樵械墓借€只是使用在服務(wù)器端和客戶端之間密鑰的交換，并由使用其來簽名。基本的思路是，將簽名服務(wù)作為SSL協(xié)議一個(gè)可選獨(dú)立擴(kuò)展功能，保證其向下兼容性；對(duì)發(fā)送的所有信息進(jìn)行簽名；利用原有的密碼資源；
6結(jié)束語
SSL雖然存在一些缺陷，但也不失為一套完善安全的網(wǎng)絡(luò)通信協(xié)議。在其廣泛的實(shí)踐中也證明了其高度的安全性。當(dāng)然，它只是網(wǎng)絡(luò)安全的一種工具。而要做到真正的安全還需要多方面的結(jié)合，這樣才可以打造一個(gè)全面的、完善的、安全可靠的網(wǎng)絡(luò)環(huán)境。
參考文獻(xiàn)：
[1]方勇.信息系統(tǒng)安全理論與技術(shù)[M].北京:高等教育出版社,2008.
[2]卿斯?jié)h.密碼學(xué)與計(jì)算機(jī)網(wǎng)絡(luò)安全[M].北京:清華大學(xué)出版社,2001.
ssl協(xié)議在傳輸層與應(yīng)用層之間對(duì)網(wǎng)絡(luò)連接加密。
SSL及其繼任者傳輸層安全是為網(wǎng)絡(luò)通信提供安全及數(shù)據(jù)完整性的一種安全協(xié)議。用以保障在Internet上數(shù)據(jù)傳輸?shù)陌踩?，利用?shù)據(jù)加密技術(shù)，可確保數(shù)據(jù)在網(wǎng)絡(luò)上的傳輸過程中不會(huì)被截取及竊聽。一般通用的規(guī)格為40bit的安全標(biāo)準(zhǔn)，美國(guó)則已推出128bit的更高安全標(biāo)準(zhǔn)。只要3.0版本的I.E或Netscape瀏覽器即可支持SSL。
SSL協(xié)議可分為兩層。SSL記錄協(xié)議它建立在可靠的傳輸協(xié)議之上，為高層協(xié)議提供數(shù)據(jù)封裝、壓縮、加密等基本功能的支持。SSL握手協(xié)議它建立在SSL記錄協(xié)議之上，用于在實(shí)際的數(shù)據(jù)傳輸開始前，通訊雙方進(jìn)行身份認(rèn)證、協(xié)商加密算法、交換加密密鑰等。
（來源：文章屋網(wǎng) ）
關(guān)鍵詞：SSL；電子商務(wù)；數(shù)據(jù)安全
1 引言
隨著計(jì)算機(jī)技術(shù)和Internet的飛速發(fā)展，商業(yè)活動(dòng)實(shí)現(xiàn)了電子化，從而發(fā)展成為電子商務(wù)。電子商務(wù)借助互聯(lián)網(wǎng)、企業(yè)內(nèi)部網(wǎng)和增值網(wǎng)等計(jì)算機(jī)與網(wǎng)絡(luò)和現(xiàn)代通信技術(shù)，按照一定的標(biāo)準(zhǔn)，利用電子化工具，將傳統(tǒng)的商業(yè)活動(dòng)的各個(gè)環(huán)節(jié)電子化、網(wǎng)絡(luò)化，從而以數(shù)字化方式來進(jìn)行交易活動(dòng)和相關(guān)服務(wù)活動(dòng)。
電子商務(wù)包括電子貨幣交換、供應(yīng)鏈管理、電子交易市場(chǎng)、網(wǎng)絡(luò)營(yíng)銷、在線事務(wù)處理、電子數(shù)據(jù)交換（EDI）、存貨管理和自動(dòng)數(shù)據(jù)收集系統(tǒng)。電子商務(wù)完全不同于傳統(tǒng)的商務(wù)活動(dòng)，它是一種以網(wǎng)絡(luò)為載體的新的商務(wù)運(yùn)作方式。
（1）SSL不能提供交易的不可否認(rèn)性。SSL協(xié)議是基于Web應(yīng)用的安全協(xié)議，它只能提供安全認(rèn)證，保證SSL鏈路上的數(shù)據(jù)完整性和保密性。卻不能對(duì)電子商務(wù)的交易應(yīng)用層的信息進(jìn)行數(shù)字簽名，因此，SSL不能提供交易的不可否認(rèn)性，這可以說是SSL在電子商務(wù)中最大的缺陷。
（2）SSL只能提供客戶機(jī)到服務(wù)器之間的兩方認(rèn)證，無法適應(yīng)電子商務(wù)中的多方交易業(yè)務(wù)。
（3）SSL易遭受Change Cipher Spec消息丟棄攻擊。由于SSL握手協(xié)議中存在一個(gè)漏洞：在finished消息中沒有對(duì)變換加密的說明消息進(jìn)行認(rèn)證處理，在接收到該消息前，所有的密碼族都不做任何加密處理和MAC保護(hù)，只有在接收到Change Cipher Spec消息之后，記錄層才開始對(duì)通信數(shù)據(jù)進(jìn)行加密和完整性保護(hù)。這種處理機(jī)制使得SSL易遭受Change Cipher Spec消息丟棄攻擊。
（4）SSL無法避免通信業(yè)務(wù)流分析攻擊。由于SSL位于TCP/IP的協(xié)議層之上，因此，無法對(duì)TCP/IP協(xié)議頭部進(jìn)行保護(hù)，導(dǎo)致潛在的隱患。攻擊者通過獲取IP地址、URL請(qǐng)求的長(zhǎng)度以及返回的Web頁面的長(zhǎng)度等信息，可以分析出用戶訪問的目標(biāo)，再加上SSL協(xié)議只支持對(duì) 塊密碼的隨機(jī)填充，沒有提供對(duì)流式密碼算法的支持，使得SSL無法阻止這類攻擊。
4 總結(jié)
電子商務(wù)正飛速地發(fā)展。用于保障電子商務(wù)活動(dòng)的安全協(xié)議主要有S-HTTP、STT、IKP、SET和SSL。其中SSL協(xié)議是目前電子商務(wù)采用的主要的網(wǎng)上交易協(xié)議。SSL協(xié)議采用了加密、認(rèn)證等安全措施，結(jié)合了Hash算法，較好地保證了數(shù)據(jù)在傳輸過程中的保密性、可靠性和完整性，在一定程度上放置了欺騙、篡改、重放等攻擊。本文在介紹SSL協(xié)議棧及其工作原理和機(jī)制的基礎(chǔ)上，對(duì)基于SSL的電子商務(wù)的安全性進(jìn)行了分析。
參考文獻(xiàn)：
[1] 邢雙慧.淺談電子商務(wù)與SSL協(xié)議[J].硅谷,2010(01):37
[關(guān)鍵詞] 電子支付 安全 SSL協(xié)議 SET協(xié)議
網(wǎng)絡(luò)和信息技術(shù)的不斷發(fā)展和滲透，使得電子商務(wù)得到了飛速的發(fā)展。然而，電子商務(wù)在提供機(jī)遇和便利的同時(shí)，也面臨著一個(gè)最大的挑戰(zhàn)，即交易的安全問題。其中，安全協(xié)議是保證電子商務(wù)安全的核心所在。
目前，國(guó)內(nèi)外使用的保障電子商務(wù)支付系統(tǒng)安全的協(xié)議包括：安全套接層協(xié)議SSL（Secure Socket Layer）、安全電子交易協(xié)議SET（Secure Electronic Transaction）等協(xié)議標(biāo)準(zhǔn)。
一、SSL協(xié)議
SSL協(xié)議是Netscape Communication公司推出在網(wǎng)絡(luò)傳輸層之上提供的一種基于RSA和保密密鑰的用于瀏覽器和Web服務(wù)器之間的安全連接技術(shù)。是對(duì)計(jì)算機(jī)之間整個(gè)會(huì)話進(jìn)行加密的協(xié)議，提供了加密、認(rèn)證服務(wù)和報(bào)文完整性。它是國(guó)際上最早應(yīng)用于電子商務(wù)的一種由消費(fèi)者和商家雙方參加的信用卡/借記卡支付協(xié)議。
1.SSL協(xié)議提供的服務(wù)主要有
(1)用戶和服務(wù)器的合法性認(rèn)證；
(2)加密數(shù)據(jù)以隱藏被傳送的數(shù)據(jù)；
(3)維護(hù)數(shù)據(jù)的完整性，確保數(shù)據(jù)能完整準(zhǔn)確地傳輸?shù)侥康牡亍?/p>
該協(xié)議主要是使用公開密鑰體制和X.509數(shù)字證書技術(shù)保護(hù)信息傳輸?shù)臋C(jī)密性和完整性，它不能保證信息的不可抵賴性，主要適用于點(diǎn)對(duì)點(diǎn)之間的信息傳輸，常用Web Server方式,它包括：服務(wù)器認(rèn)證、客戶認(rèn)證、SSL鏈路上的數(shù)據(jù)完整性和SSL鏈路上的數(shù)據(jù)保密性。對(duì)于電子商務(wù)應(yīng)用來說，使用SSL可保證信息的真實(shí)性、完整性和保密性。
2.SSL協(xié)議的工作流程
(1)接通階段：客戶通過網(wǎng)絡(luò)向服務(wù)商發(fā)送連接信息，服務(wù)商回應(yīng)；
(2)密碼交換階段：客戶與服務(wù)器之間交換雙方認(rèn)可的密碼，一般選用RSA密碼算法，也有的選用Diffie-Hellmanf和Fortezza-KEA密碼算法；
(3)會(huì)談密碼階段：客戶根據(jù)收到的服務(wù)器響應(yīng)信息，產(chǎn)生一個(gè)主密鑰，并用服務(wù)器的公開密鑰加密后傳給服務(wù)器；
(4)檢驗(yàn)階段：服務(wù)器恢復(fù)該主密鑰，并返回給客戶一個(gè)用主密鑰認(rèn)證的信息，以此讓客戶認(rèn)證服務(wù)器。
(5)客戶認(rèn)證階段：服務(wù)器通過數(shù)字簽名驗(yàn)證客戶的可信度；
(6)結(jié)束階段，客戶與服務(wù)商之間相互交換結(jié)束的信息。SSL協(xié)議運(yùn)行的基點(diǎn)是商家對(duì)客戶信息保密的承諾。從SSL 協(xié)議所提供的服務(wù)及其工作流程可以看出，該協(xié)議有利于商家而不利于消費(fèi)者?？蛻舻男畔⑹紫葌鞯缴碳遥碳议喿x后再傳給銀行，這樣，客戶資料的安全性便受到威脅。商家認(rèn)證客戶是必要的，但整個(gè)過程中，缺少了客戶對(duì)商家的認(rèn)證。在電子商務(wù)的初級(jí)階段，由于運(yùn)作電子商務(wù)的企業(yè)大多是信譽(yù)較高的大公司，因此這問題還沒有充分暴露出來。但隨著電子商務(wù)的發(fā)展，各中小型公司也參與進(jìn)來，這樣在電子支付過程中的單一認(rèn)證問題就越來越突出。雖然在SSL3.0中通過數(shù)字簽名和數(shù)字證書可實(shí)現(xiàn)瀏覽器和Web服務(wù)器雙方的身份驗(yàn)證，但是SSL協(xié)議仍存在一些問題，比如，只能提供交易中客戶與服務(wù)器間的雙方認(rèn)證，在涉及多方的電子交易中，SSL協(xié)議并不能協(xié)調(diào)各方間的安全傳輸和信任關(guān)系。在這種情況下，Visa和 MasterCard兩大信用卡公組織制定了SET協(xié)議，為網(wǎng)上信用卡支付提供了全球性的標(biāo)準(zhǔn)。
二、Set協(xié)議
Set協(xié)議是1997年5月31日由VISA和MasterCard兩大信用卡公司聯(lián)合推出的一個(gè)基于開放網(wǎng)絡(luò)的安全的以信用卡支付為基礎(chǔ)的電子商務(wù)協(xié)議。它運(yùn)用了RSA安全的公鑰加密技術(shù)，具有資料保密性、資料完整性、資料來源可辨識(shí)性及不可否認(rèn)性，是用來保護(hù)消費(fèi)者在Internet持卡付款交易安全中的標(biāo)準(zhǔn)?，F(xiàn)在，SET已成為國(guó)際上所公認(rèn)的在Internet電子商業(yè)交易中的安全標(biāo)準(zhǔn)。
1.SET支付系統(tǒng)的組成
SET支付系統(tǒng)主要由持卡人（CardHolder）、商家（Merchant）、發(fā)卡行（Issuing Bank）、收單行（Acquiring Bank）、支付網(wǎng)關(guān)（Payment Gateway）、認(rèn)證中心（Certificate Authority）等六個(gè)部分組成。對(duì)應(yīng)地，基于SET協(xié)議的網(wǎng)上購物系統(tǒng)至少包括電子錢包軟件、商家軟件、支付網(wǎng)關(guān)軟件和簽發(fā)證書軟件。
2.SET協(xié)議的工作流程如下
在SET協(xié)議介入之前，消費(fèi)者通過因特網(wǎng)進(jìn)行選貨、下訂單并與商家聯(lián)系最終確定訂單的相關(guān)情況、付款方式和簽發(fā)付款指令。此時(shí)SET協(xié)議開始介入，進(jìn)入以下幾個(gè)階段
(1)支付初始化請(qǐng)求和響應(yīng)階段。當(dāng)客戶決定要購買商家的商品并使用電子錢包支付時(shí)，商家服務(wù)器上POS軟件發(fā)報(bào)文給客戶的瀏覽器電子錢包，電子錢包要求客戶輸入口令然后與商家服務(wù)器交換“握手”信息，使客戶和商家相互確認(rèn)，即客戶確認(rèn)商家被授權(quán)可以接受信用卡，同時(shí)商家也確認(rèn)客戶是一個(gè)合法的持卡人。
(2)支付請(qǐng)求階段?？蛻舭l(fā)出一個(gè)報(bào)文，包括訂單和支付命令。在訂單和支付命令中必須有客戶的數(shù)字簽名，同時(shí)利用雙重簽名技術(shù)保證商家看不到客戶的賬號(hào)信息。而位于商家開戶行的被稱為支付網(wǎng)關(guān)的另外一個(gè)服務(wù)器可以處理支付命令中的信息。
(3)授權(quán)請(qǐng)求階段。商家收到訂單后，POS組織一個(gè)授權(quán)請(qǐng)求報(bào)文，其中包括客戶的支付命令，發(fā)送給支付網(wǎng)關(guān)。支付網(wǎng)關(guān)是一個(gè)Internet服務(wù)器，是連接Internet和銀行內(nèi)部網(wǎng)絡(luò)的接口。授權(quán)請(qǐng)求報(bào)文通過支付網(wǎng)關(guān)到達(dá)收單銀行后，收單銀行再到發(fā)卡銀行確認(rèn)。
(4)授權(quán)響應(yīng)階段。收單銀行得到發(fā)卡銀行的批準(zhǔn)后，通過支付網(wǎng)關(guān)發(fā)給商家授權(quán)響應(yīng)報(bào)文。
(5)支付響應(yīng)階段。商家發(fā)送購買響應(yīng)報(bào)文給客戶，記錄客戶交易日志，以備查詢。之后進(jìn)行發(fā)貨或提供服務(wù)，并通知收單銀行將錢從消費(fèi)者的賬號(hào)轉(zhuǎn)移到商店賬號(hào)，或通知發(fā)卡銀行請(qǐng)求支付。
三、SSL協(xié)議和SET協(xié)議的對(duì)比
1.SSL協(xié)議的優(yōu)缺點(diǎn)
SSL協(xié)議是兩層協(xié)議，建立在TCP傳輸控制協(xié)議之上、應(yīng)用層之下，并且與上層應(yīng)用協(xié)議無關(guān)，可為應(yīng)用層協(xié)議如HTTP、FTP、SMTP等提供安全傳輸，通過將HTTP與SSL相結(jié)合，Web服務(wù)器就可實(shí)現(xiàn)客戶瀏覽器與服務(wù)器間的安全通信。因此簡(jiǎn)便易行是SSL協(xié)議的最大優(yōu)點(diǎn)，但與此同時(shí)其缺點(diǎn)也是顯而易見的。首先，在交易過程中，客戶的信息先到達(dá)商家那里，這就導(dǎo)致客戶資料安全性無法保證；其次，SSL只能保證資料傳遞過程的安全性，而傳遞過程是否有人截取則無法保證；再次，由于SSL協(xié)議的數(shù)據(jù)安全性是建立在RSA等算法上，因此其系統(tǒng)安全性較差；最后，雖然SSL協(xié)議中也使用了數(shù)字簽名來保證信息的安全，但是由于其不對(duì)應(yīng)用層的消息進(jìn)行數(shù)字簽名，因此不能提供交易的不可否認(rèn)性，這就造成了SSL協(xié)議在電子銀行應(yīng)用中的最大不足。
2.SET協(xié)議的優(yōu)缺點(diǎn)
由于SET提供了消費(fèi)者、商家和銀行之間的雙重身份認(rèn)證，確保了交易數(shù)據(jù)的安全性、完整可靠性和交易的不可否認(rèn)性，特別是保證不將消費(fèi)者銀行卡號(hào)暴露給商家等優(yōu)點(diǎn)，因此它成為目前公認(rèn)的信用卡/借記卡的網(wǎng)上交易的國(guó)際安全標(biāo)準(zhǔn)。但在實(shí)際應(yīng)用中，SET協(xié)議依然存在以下不足：
(1)SET協(xié)議中仍存在一些漏洞。如：不可信的用戶可能通過其它商家的幫助欺騙可信的商家在未支付的情況下得到商品；密鑰存在被泄露的危險(xiǎn)；存在冒充持卡人進(jìn)行交易的隱患。
(2)SET協(xié)議的性能有待改進(jìn)。如：?jiǎn)渭冎С中庞每?，需要進(jìn)一步適應(yīng)借計(jì)卡的使用；協(xié)議過于復(fù)雜，要求安裝的軟件包過多，處理速度慢，價(jià)格昂貴；由于該協(xié)議的每一個(gè)階段都要進(jìn)行多次數(shù)據(jù)加密解密、簽名、證書驗(yàn)證等安全操作，因此協(xié)議的交易時(shí)間過長(zhǎng)，不能滿足實(shí)時(shí)交易要求。
3.總結(jié)
由于SSL協(xié)議的成本低、速度快、使用簡(jiǎn)單，對(duì)現(xiàn)有網(wǎng)絡(luò)系統(tǒng)不需進(jìn)行大的修改，因而目前取得了廣泛的應(yīng)用。但隨著電子商務(wù)規(guī)模的擴(kuò)大，網(wǎng)絡(luò)欺詐的風(fēng)險(xiǎn)性也在提高，在未來的電子商務(wù)中SET協(xié)議將會(huì)逐步占據(jù)主導(dǎo)地位。
參考文獻(xiàn)：
[1]徐震鄧亞平:SET的安全性分析與改進(jìn)[J]．重慶郵電學(xué)院學(xué)報(bào)，2005，17 (6),745～748
[2]馬瑞萍:SSL安全性分析研究[J];網(wǎng)絡(luò)安全技術(shù)與應(yīng)用; 2001,12期,17～20
關(guān)鍵詞:Web服務(wù);端到端安全;SSL;ESSL
中圖分類號(hào):TP309文獻(xiàn)標(biāo)識(shí)碼:A文章編號(hào):1009-3044(2009)13-3383-02
1 引言
Web 服務(wù)是一個(gè)嶄新的分布式計(jì)算模型,是Web上數(shù)據(jù)和信息集成的有效機(jī)制[3]。Web服務(wù)的新型構(gòu)架,Web服務(wù)的高效執(zhí)行方式,Web服務(wù)與其他成熟技術(shù)的有機(jī)結(jié)合以及Web服務(wù)的集成是解決現(xiàn)實(shí)應(yīng)用問題的重要技術(shù)。但是,Web 服務(wù)的安全問題也日益的突出,并逐漸成為Web 服務(wù)向前發(fā)展的一個(gè)瓶頸。當(dāng)然國(guó)內(nèi)外,Web 服務(wù)安全的研究有也不少的成果。但是還是不能夠完全滿足Web服務(wù)的端到端的安全需求。本文討論了SSL在保障Web服務(wù)安全方面不足,并在此基礎(chǔ)上提出擴(kuò)展的SSL,用以滿足Web 服務(wù)端到端的安全需求,在最后對(duì)擴(kuò)展的協(xié)議進(jìn)行分析,說明了它的優(yōu)勢(shì)以及應(yīng)用的意義。
2 SSL在Web 服務(wù)安全機(jī)制中的應(yīng)用分析
2.1 Web 服務(wù)安全需求分析
作為典型的分布式應(yīng)用,Web 服務(wù)的安全要求包括:數(shù)據(jù)的機(jī)密性、數(shù)據(jù)的完整性、不可否認(rèn)性、身份認(rèn)證、訪問控制、審計(jì)和安全管理等多個(gè)方面,同時(shí)還具有自身的特點(diǎn)[1]。對(duì)于Web 服務(wù)來說,保障其安全需要end-to-end的安全。當(dāng)然這并不是說point-to-point的安全機(jī)制以及其他的傳統(tǒng)的安全不可以應(yīng)用到Web 服務(wù),恰恰相反,由于目前大多數(shù)哦Web 服務(wù)使用http作為其傳輸層,因此在依賴于http原來的安全機(jī)制都可以在Web services中使用[1],例如防墻、SSL等。Web 服務(wù)在實(shí)施的過程中也許需要point-to-point 和end-to-end其中的一種或兩種的安全機(jī)制,這取決于受到的威脅的所處層次[1]。如果對(duì)于安全性要求不高或者威脅的層次比較低的話,像SSL、防火墻等都可以發(fā)揮很好的作用[1]。
2.2 SSL協(xié)議概述
SSL 協(xié)議(Secure Socket Layer)是Netscape 推出的一種安全通信協(xié)議,它提供Internet上保密通信的安全協(xié)議。SSL的Client和Server在正式交換應(yīng)用數(shù)據(jù)之前,需要建立會(huì)話密鑰以及有選擇地進(jìn)行身份驗(yàn)證。會(huì)話和連接是SSL的兩個(gè)重要的貫穿始終的概念。連接建立在會(huì)話的基礎(chǔ)上,每個(gè)連接與一個(gè)會(huì)話關(guān)聯(lián)。Cipher Spec和master secret組成一個(gè)會(huì)話的主要加密參數(shù),可被多個(gè)連接共享。每個(gè)連接有獨(dú)立的會(huì)話密鑰。
SSL的安全服務(wù)位于TCP和應(yīng)用層之間,對(duì)應(yīng)用層是透明的[2,5],可為應(yīng)用層如:HTTP、FTP、SMTP等提供安全業(yè)務(wù),服務(wù)對(duì)象主要是Web 應(yīng)用,即客戶瀏覽器和服務(wù)器。
SSL有三種驗(yàn)證模式[5]:
1) Client和Server都被驗(yàn)證;
2) 只驗(yàn)證Server、不驗(yàn)證Client;
3) 完全匿名。
SSL協(xié)議提供的服務(wù)可以歸納為如下三個(gè)方面[5]:
1) 連接是保密的,對(duì)稱加密用于加密數(shù)據(jù);
2) 實(shí)體的身份通過公鑰加密得到驗(yàn)證;
3) 連接是可靠的,帶密鑰的MAC用于保證信息的完整性。
2.3 和SSL在Web服務(wù)中的應(yīng)用分析
盡管SSL在Web 服務(wù)中能夠提供一定的安全保障,但是它只能夠提供點(diǎn)對(duì)點(diǎn)的安全,如圖1所示,而無法保障端到端的安全,如圖2所示,在高要求或者威脅層次較高的時(shí)候,它就無法滿足要求。在Web 服務(wù)的典型應(yīng)用中,SOAP消息往往不僅僅只是在兩個(gè)節(jié)點(diǎn)間傳輸,更多的情況下是要經(jīng)過很多的中間節(jié)點(diǎn)[6-7],而且每個(gè)中間節(jié)點(diǎn)都可能會(huì)對(duì)SOAP消息進(jìn)行處理。雖然SSL可以確保SOAP消息在兩個(gè)相鄰的節(jié)點(diǎn)之間的安全,但是由于在節(jié)點(diǎn)內(nèi)部SOAP消息是以明文出現(xiàn)的,所以,一旦其中一個(gè)節(jié)點(diǎn)受到了攻擊或者惡意的修改SOAP消息,都會(huì)造成SOAP消息的泄漏或異常。因此,SSL對(duì)于SOAP消息的端到端的安全性是不夠的[4],必須有一種更高級(jí)級(jí)別的安全機(jī)制作為保障。
3 擴(kuò)展的ESSL
為了解決上面我們提到SSL協(xié)議在保障Web服務(wù)安全中的不足,對(duì)SLL進(jìn)行擴(kuò)展,稱之為擴(kuò)展的SSL協(xié)議(Extended SSL,簡(jiǎn)稱ESSL),這個(gè)改進(jìn)保留了SSL原有的安全特性,又可以滿足Web服務(wù)的end-to-end的安全需求。(ESSL術(shù)語只在本文中適用)
3.1 相關(guān)標(biāo)記
為了準(zhǔn)確表達(dá),我們使用下面標(biāo)記:
Ii:第i個(gè)節(jié)點(diǎn),其中I1是消息的原始發(fā)送者(Requester/Provider),In是消息最終收到的消息的(Requester/Provider),0
info:原始的信息
infoi:經(jīng)過Ii修改后的信息,由Ii加密后發(fā)送給Ii+1
Ceri:Ii的證書
h():使用安全的hash函數(shù)進(jìn)行對(duì)消息的摘要
ski:Ii的私鑰
pki:Ii的公鑰
sgni:Ii數(shù)字的簽名
Sign(ski,m):Ii用自己的私鑰對(duì)消息m進(jìn)行數(shù)字簽名
Rec(pki,s):用Ii的公鑰對(duì)簽名s進(jìn)行驗(yàn)證
E(pki,m):用Ii的公鑰加密消息m
D(ski,s):Ii用自己的私鑰解密加密的消息s
ki:Ii隨機(jī)生成的對(duì)稱密鑰
E(ki,m):用ki進(jìn)行加密
D(ki,s):用ki進(jìn)行解密
3.2 協(xié)議的流程的詳細(xì)描述
首先要說明的是,兩個(gè)相互通信的節(jié)點(diǎn),在進(jìn)行消息的傳遞之前要進(jìn)行握手,在握手的過程主要是交換相互的數(shù)字證書以及協(xié)商相關(guān)的加密算法等。
協(xié)議的流程如下:
1) I1:生成簽名:sgn1=Sign(sk1,h(info)),加密信息:E(k1,info),生成數(shù)字信封:E(pk2,k1),I1把(sgn1,E(k1,info),E(k1,info),E(pk2,k1),(sgn1,Cer1))發(fā)送給下一個(gè)通信節(jié)點(diǎn)。
2) 中間節(jié)點(diǎn)Ii(1
3) In:收到消息(sgnn-1,E (kn-1,infon-1), E (kn-1,info),E(pkn,kn-1),(sgn1,Cer1,)),In首先解開數(shù)字信封D(skn,E(pkn,kn-1)),獲得對(duì)稱密鑰kn-1,然后獲取信息info=D(kn-1,E(kn-1,info))和infon-1= D(kn-1,E(kn-1,infon-1)),驗(yàn)證In-1的簽名Rec (pkn-1,sgnn-1)=h(D(kn-1,E(kn-1,infon-1)))?,然后在驗(yàn)證I1的簽名和原始信息的完整性Rec (pk1,sgn1)=h(D(kn-1,E(kn-1,info)))?。如果驗(yàn)證通過就進(jìn)行下一步的操作,如果沒有就終止通信。
協(xié)議中對(duì)消息的解密以及驗(yàn)證的流程如圖3所示。
協(xié)議中對(duì)消息加密處理的流程圖如圖4所示。
說明:當(dāng)i=1的時(shí)候,虛線框中的處理過程就不需要了,因?yàn)閕nfo1=info
4 ESSL協(xié)議的分析
4.1 安全性分析
從ESSL的流程可以看出,SSL原有的安全機(jī)制都被包含,同時(shí)由于在消息中加入原始信息發(fā)送者對(duì)原始信息的簽名以及它的數(shù)字證書,另外在原始信息和修改后的信息都被發(fā)送到最終接收者In那里,這樣最終的接收者In不僅能夠看出來中間節(jié)點(diǎn)對(duì)原始信息的修改,同時(shí)還可以驗(yàn)證原始的信息及其簽名和消息的完整性。另外,協(xié)議使用原來的數(shù)字信封以及對(duì)稱加密,使得消息的機(jī)密性也有了保障。(下轉(zhuǎn)第3397頁)
(上接第3384頁)
綜上所述,使用ESSL可以保證Web服務(wù)端到端的安全。
4.2 速度分析
為了能夠達(dá)到端到端的安全需求,ESSL多發(fā)送了很多“冗余”的信息并且做了附加的加密和驗(yàn)證,這樣對(duì)于傳送的速度以及驗(yàn)證速度勢(shì)必有所影響。但是,為了信息的安全或者特殊的安全需要,可以用性能換取高安全。
5 結(jié)束語
該文分析了Web服務(wù)的安全需求,指出了現(xiàn)有的SSL在保障Web服務(wù)安全中存在的不足,并在SSL協(xié)議的基礎(chǔ)上做出了改進(jìn),提出了ESSL,使其達(dá)到Web服務(wù)端到端的安全需求,從而能夠保障Web 服務(wù)的端到端的安全。另外,在其它要求端到端安全的環(huán)境中,ESSL也有著廣泛的用途。
參考文獻(xiàn):
[1] Web Services Architecture[EB/OL].(2004-02)./2002/ws/.
[2] 宋志敏,王衛(wèi)京,南相浩.SSL V3.0及其安全性分析[J].計(jì)算機(jī)工程與應(yīng)用2000(10):145-147.
[3] 岳昆,王曉玲,周傲.Web 服務(wù)核心支撐技術(shù):研究綜述[J].軟件學(xué)報(bào),2004,15(3):428-442.
[4] IBM Corporation.Web Service Conceptual Architecture (WSCA1.0) [EB/OL]./developerworks/cn/views/webservices/libraryview.jsp.
[5] 范紅,馮登國(guó).安全協(xié)議理論與方法[M].北京:科學(xué)出版社,2003.
[6] 錢權(quán),嚴(yán)家德.Web Service的安全機(jī)制[J].計(jì)算機(jī)工程,2007,33(22):190-192.
[7] 石偉鵬,楊小虎.基于SOAP協(xié)議的Web Service安全基礎(chǔ)規(guī)范(WS-Security)[J].計(jì)算機(jī)應(yīng)用研究,2003(2):100-102.
關(guān)鍵詞：TLS1.2；安全協(xié)議；計(jì)算模型
中圖分類號(hào)：TP393
文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)：1672-7800（2015）005-0154-04
作者簡(jiǎn)介：牛樂園（1990-），女，河南許昌人，中南民族大學(xué)計(jì)算機(jī)科學(xué)學(xué)院碩士研究生，研究方向?yàn)樾畔踩?/p>
0 引言
人類建立了通信系統(tǒng)后，如何保證通信安全始終是一個(gè)重要問題。伴隨著現(xiàn)代通信系統(tǒng)的建立，人們利用數(shù)學(xué)理論找到了一些行之有效的方法來保證數(shù)字通信安全。簡(jiǎn)單而言就是將雙方通信的過程進(jìn)行保密處理，比如對(duì)雙方通信的內(nèi)容進(jìn)行加密，這樣可有效防止偷聽者輕易截獲通信內(nèi)容。SSL（Secure Sockets Layer） 及其后續(xù)版本 TLS（Transport Layer Security）是目前較為成熟的通信加密協(xié)議，常被用于在客戶端和服務(wù)器之間建立加密通信通道。TLS是安全傳輸層協(xié)議，用于在兩個(gè)通信應(yīng)用程序之間提供保密性和數(shù)據(jù)完整性。截至目前其版本有1.0，1.1、1.2[1]，由兩層協(xié)議組成：TLS 記錄協(xié)議（TLS Record）和 TLS 握手協(xié)議（TLS Handshake）。
1 TLS協(xié)議結(jié)構(gòu)
TLS協(xié)議是對(duì)SSL協(xié)議規(guī)范后整理的協(xié)議版本，建立在可靠的傳輸層上，如TCP（UDP則不行）。應(yīng)用層可利用TLS協(xié)議傳輸各種數(shù)據(jù)，來保證數(shù)據(jù)的安全性和保密性[2]。
安全傳輸層協(xié)議（TLS）用于在兩個(gè)通信應(yīng)用程序之間提供保密性和數(shù)據(jù)完整性。該協(xié)議由兩層組成：TLS 記錄協(xié)議（TLS Record）和TLS握手協(xié)議（TLS Handshake）。較低層為 TLS記錄協(xié)議，位于某個(gè)可靠的傳輸協(xié)議（如TCP）上。
TLS記錄協(xié)議是一種分層協(xié)議。每一層中的信息可能包含長(zhǎng)度、描述和內(nèi)容等字段。記錄協(xié)議支持信息傳輸、將數(shù)據(jù)分段到可處理塊、壓縮數(shù)據(jù)、應(yīng)用 MAC、加密以及傳輸結(jié)果等，并對(duì)接收到的數(shù)據(jù)進(jìn)行解密、校驗(yàn)、解壓縮、重組，然后將它們傳送到高層客戶機(jī)。
TLS記錄層從高層接收任意大小不間斷的連續(xù)數(shù)據(jù)。密鑰計(jì)算：記錄協(xié)議通過算法從握手協(xié)議提供的安全參數(shù)中產(chǎn)生密鑰、IV 和 MAC 密鑰。TLS 握手協(xié)議由3個(gè)子協(xié)議組構(gòu)成，允許對(duì)等雙方在記錄層的安全參數(shù)上達(dá)成一致、自我認(rèn)證、例示協(xié)商安全參數(shù)、互相報(bào)告出錯(cuò)條件。
TLS握手協(xié)議由3種協(xié)議封裝，包括改變密碼規(guī)格協(xié)議、警惕協(xié)議、握手協(xié)議。TLS協(xié)議結(jié)構(gòu)如圖1所示。
2 TLS1.2消息流程
在整個(gè)通訊過程中，為實(shí)現(xiàn)TLS的安全連接，服務(wù)端與客戶端要經(jīng)歷如下5個(gè)階段[3]：①Client申請(qǐng)鏈接，包含自己可以實(shí)現(xiàn)的算法列表以及其它信息；②Server回應(yīng)鏈接，回應(yīng)中確定了這次通信所使用的算法，將證書發(fā)送給對(duì)方，證書中包含了自己的身份和公鑰；③Client在收到消息后會(huì)生成一個(gè)秘密消息ClientKeyExchange――（此秘密消息經(jīng)處理后，將用作加密密鑰（會(huì)話密鑰）），用Web服務(wù)器的公鑰加密并傳至Server；④Server再用私鑰解密秘密消息ClientKeyExchange，并進(jìn)行處理，生成會(huì)話密鑰（用于之后的數(shù)據(jù)加密），會(huì)話密鑰協(xié)商成功；⑤Client和Server得到會(huì)話密鑰，并用此會(huì)話密鑰進(jìn)行數(shù)據(jù)加密。
TLS1.2在傳輸層協(xié)議的消息主要包含8條消息，消息結(jié)構(gòu)如圖2所示，分別是ClientHello版本協(xié)商、ServerHello版本協(xié)商、Server Certificate證書消息、HelloDone接收結(jié)束標(biāo)識(shí)、 ClientKeyExchange即Client交換密鑰消息、Client的Finished消息、CertificateVeri驗(yàn)證證書消息、Server的Finished消息。
2.1 ClientHello和消息
ClientServer
client_version|| client_random|| session_id|| cipher_suites|| compression_methods|| extensions
消息描述：該消息包括客戶端的版本號(hào)client_version，用于告知服務(wù)器client可以支持的協(xié)議最高版本，來協(xié)商安全協(xié)議版本。client_random是client產(chǎn)生的一個(gè)隨機(jī)數(shù)，由client的日期和時(shí)間加上28字節(jié)的偽隨機(jī)數(shù)組成，用于后面的主密鑰計(jì)算。session_id由服務(wù)連接得到，發(fā)送給server來建立一個(gè)新的會(huì)話連接。cipher_suites是client提供給server可供選擇的密碼套件，用于協(xié)商密鑰交換，數(shù)據(jù)加密以及散列算法。compression_methods是客戶端支持的壓縮算法。extensions是客戶端的擴(kuò)展域。
client_version： Protocol version（協(xié)議版本），該字段表明了客戶能夠支持的最高協(xié)議版本3.3。
random：它由客戶的日期和時(shí)間加上28字節(jié)的偽隨機(jī)數(shù)組成，該客戶隨機(jī)數(shù)將用于計(jì)算master secret（主秘密）和prevent replay attacks（防止重放攻擊）。
session_id：一個(gè)會(huì)話ID標(biāo)識(shí)一個(gè)可用的或者可恢復(fù)的會(huì)話狀態(tài)。一個(gè)空的會(huì)話ID表示客戶想建立一個(gè)新的TLS連接或者會(huì)話，而一個(gè)非空的會(huì)話ID表明客戶想恢復(fù)一個(gè)先前的會(huì)話。session_id有3個(gè)來源：①之前的會(huì)話連接；②當(dāng)前連接，客戶端僅僅想通過更新random結(jié)構(gòu)得到連接值時(shí)使用；③當(dāng)前激活的連接，為了建立幾個(gè)獨(dú)立的連接而不再重復(fù)發(fā)起連接握手。
2.2 ServerHello消息
ServerClient：
server_version||server_random|| session_id|| cipher_suites|| compression_methods|| extensions
消息描述：該消息包含6個(gè)消息項(xiàng)，server_version取客戶端支持的最高版本號(hào)和服務(wù)端支持的最高版本號(hào)中的較低者，本文所用的是TLS1.2。server _random是服務(wù)端生成的隨機(jī)數(shù)，由服務(wù)器的時(shí)間戳加上28字節(jié)的偽隨機(jī)數(shù)組成，也用于主密鑰的生成。session_id提供了與當(dāng)前連接相對(duì)應(yīng)的會(huì)話的標(biāo)識(shí)信息。從客戶端處接收到會(huì)話標(biāo)識(shí)后，服務(wù)器將查找其緩存以便找到一個(gè)匹配的session_id。
server_version： Protocol version（協(xié)議版本），取客戶端支持的最高版本號(hào)和服務(wù)端支持的最高版本號(hào)中的較低者。TLS版本為3.3。random：它由客戶的日期和時(shí)間加上28字節(jié)的偽隨機(jī)數(shù)組成，該客戶隨機(jī)數(shù)將用于計(jì)算master secret（主秘密）和prevent replay attacks（防止重放攻擊）。session_id：該域提供了與當(dāng)前連接相對(duì)應(yīng)的會(huì)話的標(biāo)識(shí)信息。如果從客戶端接收到的會(huì)話標(biāo)識(shí)符非空，則服務(wù)器將查找其緩存以便找到一個(gè)匹配。
2.3 Server Certificate消息
ServerClient：
version||serialNumber||algorithmIdentifier||issuer||utcTime||subject_name||subject_key_info|| signature
消息描述：該項(xiàng)消息為可選項(xiàng)，證書主要包含4部分內(nèi)容，version是證書版本，文章統(tǒng)一定為X509v3。主體名稱指明使用該證書的用戶為server_subject。subject_key_info是證書包含的公鑰信息，該消息項(xiàng)有兩項(xiàng)內(nèi)容：一個(gè)是證書的公鑰，發(fā)送給client后用于加密client生成的預(yù)主密鑰，并把密文信息發(fā)送給server。server收到該密文信息后可以使用自己的私鑰解密得到預(yù)主密鑰；另一個(gè)是所用的散列算法。signature：證書驗(yàn)證簽名信息，用以驗(yàn)證證書。version：證書版本號(hào)，為X.509V3。subject_name：證書主體名稱。
subject_key_info：標(biāo)識(shí)了兩個(gè)重要信息：①主體擁有的公鑰的值；②公鑰所應(yīng)用算法的標(biāo)識(shí)符。證書私鑰對(duì)證書的所有域及這些域的Hash值一起加密。
2.4 ServerKeyExchange消息
ServerClient：
KeyExchangeAlgorithm|| ServerDHParams
KeyExchangeAlgorithm：密鑰交換算法，文章定義的密鑰交換算法為RSA。ServerDHParams：Diffi-Hellman參數(shù)，若交換算法為RSA，則此項(xiàng)為空。
2.5 CertificateRequest消息
ServerClient：
certificate_types|| supported_signature_algorithms|| certificate_authorities
消息描述： 可選消息項(xiàng)，該消息是Server服務(wù)器向Client請(qǐng)求驗(yàn)證證書信息。在一般應(yīng)用中只對(duì)Server服務(wù)器進(jìn)行認(rèn)證，而Server服務(wù)器要允許只有某些授權(quán)的Client才能訪問服務(wù)器，此時(shí)需要用到該消息對(duì)Client進(jìn)行認(rèn)證。Client認(rèn)證是通過Server服務(wù)器給Client發(fā)送一條 CertificateRequest消息而開始，如果Server發(fā)送這條消息，則Client必須向server發(fā)送自己的證書?？蛻舳耸盏皆撓⒑?，發(fā)送一條 Certifcate 消息（與服務(wù)器傳送證書的消息一樣）和一條 CertificateVerify 消息予以應(yīng)答。
certificate_type：客戶端提供的證書類型，該處為rsa_sign。supported_signature_algorithms：可以驗(yàn)證server的散列/簽名算法對(duì)。certificate_authorities：可以接受證書消息的特定名稱。
2.6 Client Certificate消息
ClientServer：
version||serialNumber||algorithmIdentifier||issuer||utcTime||subject_name||subject_key_info|| signature
消息描述：可選消息項(xiàng)，該證書主要包含4部分內(nèi)容，version是證書版本，文章統(tǒng)一定為X509v3。主體名稱指明使用該證書的用戶為server_subject。subject_key_info是證書包含的主要公鑰信息，該消息項(xiàng)有兩項(xiàng)內(nèi)容：一個(gè)是證書的公鑰，另一個(gè)是所用的散列算法。signature是證書驗(yàn)證簽名信息，用以驗(yàn)證證書。
version：證書的版本號(hào)，為X.509V3。subject_name：證書主體名稱。subject_key_info：標(biāo)識(shí)了兩個(gè)重要信息：①主體擁有的公鑰的值；②公鑰所應(yīng)用的算法的標(biāo)識(shí)符。算法標(biāo)識(shí)符指定公鑰算法和散列算法（如RSA和SHA-1）。signature：用證書私鑰對(duì)證書的所有域及這些域的Hash值一起加密。
2.7 ClientKeyExchange消息
ClientServer：
KeyExchangeAlgorithm|| EncryptedPreMasterSecret
消息描述：該消息是密鑰交換消息。之前的消息協(xié)商中規(guī)定密鑰交換算法為RSA算法，所以該消息中KeyExchangeAlgorithm的內(nèi)容為RSA。此時(shí)，client隨機(jī)生成一個(gè)48字節(jié)的預(yù)主密鑰，用從server證書得來的公鑰來加密這個(gè)預(yù)主密鑰，加密算法為RSA算法。client加密預(yù)主密鑰并在ClientKeyExchange消息中將密文EncryptedPreMasterSecret發(fā)給server，使server得到預(yù)主密鑰。
KeyExchangeAlgorithm：算法選擇為RSA。EncryptedPreMasterSecret：客戶端生成一個(gè)48字節(jié)的預(yù)主密鑰，用從server證書得來的公鑰來加密該預(yù)主密鑰，加密預(yù)主密鑰消息并發(fā)送密文。
2.8 CertificateVerif消息
ClientServer
handshake_messages[handshake_messages_length]
消息描述：可選消息項(xiàng)，如果服務(wù)器請(qǐng)求驗(yàn)證客戶端，則該消息完成服務(wù)器驗(yàn)證過程?？蛻舳税l(fā)送一個(gè)certificate_verify消息，其中包含一個(gè)簽名，對(duì)從第一條消息以來的所有握手消息的HMAC值（用master_secret）進(jìn)行簽名。handshake_messages指所有發(fā)送或接收的握手消息，從clienthello消息開始到CertificateVerif消息之前（不包括CertificateVerif消息）的所有消息集合，包括握手消息的類型和變長(zhǎng)字段。這是到目前為止HandShake結(jié)構(gòu)的整合。
3 Blanchet演算模型建立流程
Blanchet演算模型主要包括類型定義、時(shí)間定義、方法定義、通道定義、時(shí)間聲明、初始化進(jìn)程描述[4]、客戶端進(jìn)程描述與服務(wù)端進(jìn)程描述。TLS1.2最主要的功能體現(xiàn)在客戶端與服務(wù)端的消息傳遞。
3.1 協(xié)議事件聲明
在Blanchet演算中首先要聲明要證明的事件。TLS1.2協(xié)議的消息流程中最重要的就是認(rèn)證性和密鑰的保密性[5]。認(rèn)證性包括客戶端對(duì)服務(wù)端的認(rèn)證和服務(wù)端對(duì)客戶端的認(rèn)證，保密性是對(duì)會(huì)話密鑰的秘密性進(jìn)行認(rèn)證。表示server事件發(fā)生之前client事件一定發(fā)生，用來驗(yàn)證服務(wù)端用戶。在更嚴(yán)格的定義下進(jìn)行服務(wù)端驗(yàn)證，事件聲明代碼如下。
event server（output）.
event client（output）.
query x：output；
event server（x）==>client（x）.
query x：output；
event inj：server（x）==>inj：client（x）.
query secret premastersecret.
3.2 初始化進(jìn)程
協(xié)議模型初始化進(jìn)程如下所示，ClientProcess表示客戶端進(jìn)程[6]，ServerProcess表示服務(wù)端端進(jìn)程，表示多個(gè)ClientProcess進(jìn)程并發(fā)執(zhí)行，集中一次模擬現(xiàn)實(shí)協(xié)議執(zhí)行。
process
in（start，（））；
new seedone：rsakeyseed；
let pkeyrsa：rsapkey=rsapkgen（seedone） in
let skeyrsa：rsaskey=rsaskgen（seedone） in
new seedtwo：keyseed；
let signpkey：pkey=pkgen（seedtwo） in
let signskey：skey=skgen（seedtwo） in
new keyhash：hashkey；
out（c，（pkeyrsa，signpkey，keyhash））；
（（！ N ClientProcess） |
（！ N ServerProcess） ）
3.3 客戶端和服務(wù)端進(jìn)程
客戶端的消息流程包括版本協(xié)商、算法協(xié)商、密鑰協(xié)商、密鑰交換和請(qǐng)求驗(yàn)證。版本協(xié)商是協(xié)商客戶端、服務(wù)端可以通用的版本[7]，一般是客戶端和服務(wù)端都支持的最高版本，密鑰協(xié)商完成后Client向Server發(fā)送verifydata認(rèn)證請(qǐng)求消息，內(nèi)容包括username、servicename、methodname，method_specific，請(qǐng)求Server驗(yàn)證身份，并在此定義對(duì)客戶端的驗(yàn)證事件client（verifydata）。
服務(wù)端進(jìn)程首先接收客戶端進(jìn)程發(fā)送的版本信息[8]，并與自己的版本信息匹配協(xié)商得到協(xié)商版本client_version。版本信息協(xié)商完成后接收客戶端所支持的算法信息，至此算法協(xié)商完成。進(jìn)入密鑰協(xié)商階段，首先Server接收Client發(fā)送的密鑰參數(shù)信息c_s_random_s，用來計(jì)算hash驗(yàn)證；Server收到Client的驗(yàn)證請(qǐng)求后對(duì)Client進(jìn)行驗(yàn)證并接收Client發(fā)來的驗(yàn)證消息，用所收到的所有消息計(jì)算驗(yàn)證信息。在此插入事件event server（verifydata_fc）來驗(yàn)證客戶端。
3.4 驗(yàn)證結(jié)果
本文在介紹TLS1.2協(xié)議的基礎(chǔ)上對(duì)其數(shù)據(jù)流程進(jìn)行分析[9]，使用Blanchet建立模型并分析其安全性和認(rèn)證性。經(jīng)過一系列的流程跟進(jìn)并使用自動(dòng)化證明工具Cryptoverif對(duì)TLS1.2進(jìn)行模型建立，經(jīng)過一系列的Game轉(zhuǎn)換得出分析結(jié)果如圖3所示[10]。結(jié)果證明，TLS1.2協(xié)議的會(huì)話密鑰具有安全性，在認(rèn)證階段能夠?qū)蛻舳送ㄟ^消息簽名進(jìn)行驗(yàn)證。
4 結(jié)語
為了研究TLS1.2協(xié)議在應(yīng)用中的安全性，本文對(duì)TLS1.2協(xié)議的消息流程進(jìn)行了分析。通過對(duì)每一步消息流中消息項(xiàng)的研究分析，得出TLS1.2協(xié)議的整體消息結(jié)構(gòu)，最終實(shí)現(xiàn)服務(wù)端對(duì)客戶端的驗(yàn)證流程分析?；贐lanchet演算對(duì)分析的消息流程應(yīng)用一致性對(duì)服務(wù)端認(rèn)證客戶端和客戶端對(duì)服務(wù)端的驗(yàn)證建立模型。協(xié)議模型通過協(xié)議轉(zhuǎn)換工具轉(zhuǎn)換為CryptoVerif的輸入代碼TLS1.2.cv，使用CryptoVerif對(duì)模型進(jìn)行分析，并證明了TLS1.2協(xié)議的安全性與認(rèn)證性。后續(xù)研究中將給出TLS1.2協(xié)議的Java安全代碼，并分析其安全性。
參考文獻(xiàn)：
[1] 陳力瓊，陳克非.認(rèn)證測(cè)試方法對(duì)TLS協(xié)議的分析及其應(yīng)用[J].計(jì)算機(jī)應(yīng)用與軟件，2008，25（11）：6-7.
[2] 于代榮，楊揚(yáng)，馬炳先，等.基于身份的TLS協(xié)議及其BAN邏輯分析[J].計(jì)算機(jī)工程，2011，37（1）：142-144.
[3] MORRISSEY P， P SMART N，WARINSCHI B.The TLS handshake protocol： a modular analysis[J]. Journal of Cryptology，2010，23（2）：187-223.
[4] 盧敏，申明冉.基于RSA簽名的TLS協(xié)議的新攻擊發(fā)現(xiàn)及其改進(jìn)[J].消費(fèi)電子，2013（14）：69-70.
[5] 高志偉，耿金陽.基于優(yōu)先級(jí)策略的 TLS 握手協(xié)議研究[J].石家莊鐵道大學(xué)學(xué)報(bào)：自然科學(xué)版，2014（3）：69-74.
[6] 唐鄭熠，李祥.Dolev-Yao攻擊者模型的形式化描述[J].計(jì)算機(jī)工程與科學(xué)，2010（8）：36-38.
[7] 邵飛.基于概率進(jìn)程演算的安全協(xié)議自動(dòng)化分析技術(shù)研究[D].武漢：中南民族大學(xué)，2011.
[8] 朱玉娜.密碼協(xié)議符號(hào)分析方法的計(jì)算可靠性研究[D].鄭州：信息工程大學(xué)，2008.
本文通過著重闡述對(duì)HONEYWELL PKS 和S7-200的modbus rtu 通訊的各種參數(shù)的設(shè)置，以實(shí)現(xiàn)HONEYWELLPKS 和S7-200之間的通訊。
主要參數(shù)設(shè)備：S7-200CPUMBUS_INIT MBUS_SLAVE終端服務(wù)器 交換機(jī)等
中圖分類號(hào)：TP368文獻(xiàn)標(biāo)識(shí)碼： A
引言：
在鞍山熱能研究院碳素總廠針狀焦工程中，通過一年多的工作，我們通過在HONEYWELL PKS 的畫面與下位機(jī)的編程調(diào)試過程中，接觸了多種通訊協(xié)議，使我對(duì)HONEYWELL PKS 和S7-200之間的通訊有個(gè)更深刻的認(rèn)識(shí)，以下是我對(duì)HONEYWELL PKS與S7-200之間MODBUS RTU從站協(xié)議通訊的論述。
在S7-200中MODBUS RTU從站指令庫只支持CPU上的通信0口（Port0）, 是通過S7-200的自由口通信模式實(shí)現(xiàn)，它支持 STEP 7-Micro/WIN32 V3.2以上版本的編程軟件，通訊前我們要檢查Micro/WIN的指令樹中是否存在MODBUS RTU從站指令庫，庫中應(yīng)當(dāng)包括MBUS_INIT和MBUS_SLAVE兩個(gè)子程序。如果沒有，必須安裝Micro/WIN32 V3.2的Instruction Library（指令庫）軟件包，如圖：
在編程時(shí)，我們一般使用SM0.1 來初始化MBUS_INIT，使用SM0.0來調(diào)用MBUS_SLAVE。
在我們對(duì)MBUS_INIT和MBUS_SLAVE進(jìn)行編程設(shè)置時(shí)，我們一定要先明白每個(gè)管腳的意義與作用，下面我們對(duì)管腳逐一的剖析認(rèn)識(shí)一下。
圖1
在MBUS_INIT中，Mode模式選擇：?jiǎn)?dòng)／停止MODBUS, 1=啟動(dòng)；0=停止
Addr 從站地址：MOUBUS從站地址，取值1~247
Baud 波特率：可選1200，2400，4800，9600，19200，38400，57600，115200
Parity奇偶校驗(yàn): 0=無校驗(yàn)；1=奇校驗(yàn)；2=偶校驗(yàn)
Delay 延時(shí)：附加字符間延時(shí)，缺省值為0
MaxIQ最大I/Q位：參與通信的最大I/O點(diǎn)數(shù)，S7-200的I/O映像區(qū)為128/128，缺省值為128
MaxAI最大AI字?jǐn)?shù)：參與通信的最大AI通道數(shù)，可為16或32 MaxHold最大保持寄存器區(qū)：參與通信的V存儲(chǔ)區(qū)字（VW）
Holdst～保持寄存器區(qū)起始地址：以&VBx指定（間接尋址方式）
Done : 初始化完成標(biāo)志：成功初始化后置1
Error :初始化錯(cuò)誤代碼
在MBUS_SLAVE中，Done :MODBUS執(zhí)行：通信中時(shí)置1，無MODBUS通信活動(dòng)時(shí)為 0
Error : 錯(cuò)誤代碼：0=無錯(cuò)誤
MaxHold和HoldStart指定的保持寄存器區(qū)，是在S7-200 CPU的V數(shù)據(jù)存儲(chǔ)區(qū)中分配，此數(shù)據(jù)區(qū)不能和庫指令數(shù)據(jù)區(qū)有任何重疊，否則在運(yùn)行時(shí)會(huì)產(chǎn)生錯(cuò)誤，不能正常通信。我們一定要注意Modbus 中的保持寄存器區(qū)是按“字”尋址，即MaxHold規(guī)定的是VW而不是VB的個(gè)數(shù)。在圖1的例子中，規(guī)定了 MODBUS 保持寄存器區(qū)從 VB700開始（HoldStart ＝ VB700，保持區(qū)不一定要從VB0開始），并且保持寄存器為500個(gè)字（MaxHold＝500），因保持寄存器以字（兩個(gè)字節(jié)）為單位，實(shí)際上這個(gè)通信緩沖區(qū)占用了VB700～VB1699共1000個(gè)字節(jié)。因此分配庫指令保留數(shù)據(jù)區(qū)時(shí)不能在VB700～VB1699之內(nèi)。同時(shí)我們要注意的是V存儲(chǔ)區(qū)大小與CPU型號(hào)有關(guān)，不同型號(hào)的CPU的V數(shù)據(jù)存儲(chǔ)區(qū)大小不同，所以我們應(yīng)根據(jù)需要選擇MODBUS保持寄存器區(qū)域的大小.在這里我們對(duì)MBUS_INIT和MBUS_SLAVE進(jìn)行如圖1的設(shè)置。
我們通過一個(gè)終端服務(wù)器來實(shí)現(xiàn)485通訊轉(zhuǎn)換為以太網(wǎng)通訊，如圖2：
485通訊電纜
以太網(wǎng)通訊電纜
以太網(wǎng)通訊電纜
圖2
注意：用以太網(wǎng)線連接終端服務(wù)器和交換機(jī)時(shí)，要注意它們連接的端口間的傳輸速率是否相同，不相
同一定要把它們?cè)O(shè)為相同的傳輸速率，這樣終端服務(wù)器和交換機(jī)之間才能進(jìn)行通訊。
在S7-200與MODBUS的地址轉(zhuǎn)換中我們參照如圖3：
Modbus地址 S7-200數(shù)據(jù)區(qū)
00001 ~ 00128 Q0.0 ~ Q15.7
10001 ~ 10128 I0.0 ~ I15.7
30001 ~ 30032 AIW0 ~ AIW62
40001 ~ 4xxxx T ~ T + 2 * (xxxx -1)
圖3
T代表S7-200中的起始地址的數(shù)值，如圖1中HoldStart ＝ VB700，T就等于700.對(duì)應(yīng)的MODBUS地址就是40001.
在HONEYWELLPKS中，我們要在QuickBuilder （CONFIGURATIONSTUDIOCONTROLSTRATEGYSCADACONTROL）中對(duì)通道、控制器、點(diǎn)進(jìn)行設(shè)置，如圖4
圖4
在進(jìn)入下面的畫面時(shí)，我們單擊圖5標(biāo)欄中的“+”會(huì)彈出一個(gè)窗口如圖6：
圖5