引論：我們?yōu)槟砹?3篇ssl協(xié)議范文，供您借鑒以豐富您的創(chuàng)作。它們是您寫作時(shí)的寶貴資源，期望它們能夠激發(fā)您的創(chuàng)作靈感，讓您的文章更具深度。
篇1
ssl Protocol Analysis and Implementation
HU Xiao-ye1,LI Jun-yi2
(1.Baoji University of Arts and Sciences Equipment Department,Baoji 721007,China; 2.Dept. Comput. Sci. & tech., Shanxi Police Profession College,Xi'an 710043,China)
Abstract: Aim Discuss the configuration and working process of the SSL protocol,apply SSL to achieve internet security.Means First understand the system construction of SSL protocol,then understand the protocol's working process by SSL communicate and handclasp protocol process.Result SSL protocol is a security protocol base on the TCP/IP,SSL protocol settle the problem of security on internet,make up the shortage of TCP/IP,give us security of data transfer in internet.Conclusion Discussing the configuration and working process of the SSL protocol, make us to understand the SSL protocol all-around, and bring forward it's shortage and consummate it.
Key words: SSL protocol;C/S configuration;handclasp protocol;TCP/IP protocol
1 引言
目前，隨著Internet的快速發(fā)展，互聯(lián)網(wǎng)上的信息安全越來越引起人們的關(guān)注。特別是近年來基于互聯(lián)網(wǎng)的網(wǎng)上銀行、電子商務(wù)和電子政務(wù)的發(fā)展，如何保證傳輸信息，特別是網(wǎng)上交易信息的不可否認(rèn)性、保密性、完整性已成為急待解決的問題。為此，人們發(fā)明了安全套接層SSL協(xié)議(Security Socket Layer Protocol，簡(jiǎn)稱SSL)，是Internet上使用廣泛的保密通信的一種安全協(xié)議。
2 概述
SSL協(xié)議是由Netscape公司為制定數(shù)據(jù)安全性所開發(fā)的通信協(xié)議。1995年，Netscape公司提出了SSL2.0之后，很快就成為一個(gè)事實(shí)上的標(biāo)準(zhǔn)，并為眾多的廠商所采用。1996年，Netscape公司了SSL3.0，該版本增加了對(duì)除了RSA算法之外的其他算法的支持和一些安全特性，并且修改了前一個(gè)版本中一些小的問題，相比SSL2.0更加成熟和穩(wěn)定。1999年l月EITF基于SSL協(xié)議了TLS1.0(Transport Layer Security)版本，Netscape公司宣布支持該開放的標(biāo)準(zhǔn)。
SSL協(xié)議向基于TCP/護(hù)的客戶/服務(wù)器應(yīng)用程序提供了客戶端和服務(wù)器的鑒別、數(shù)據(jù)完整性、及信息機(jī)密性等安全措施。該協(xié)議通過在應(yīng)用程序進(jìn)行數(shù)據(jù)交換前交換SSL初始握手信息來實(shí)現(xiàn)有關(guān)安全特性的審查。在SSL握手信息中采用了DES、MDS等加密技術(shù)來實(shí)現(xiàn)機(jī)密性和數(shù)據(jù)完整性，并采用X.509的數(shù)字證書實(shí)現(xiàn)鑒別。該協(xié)議已成為事實(shí)上的工業(yè)標(biāo)準(zhǔn)，并被關(guān)泛應(yīng)用于Internet和Intranet的服務(wù)器產(chǎn)品和客戶端產(chǎn)品中。如Netscape公司、微軟公司、IBM公司等領(lǐng)導(dǎo)Internet/Intranet網(wǎng)絡(luò)產(chǎn)品的公司已在使用該協(xié)議。
3 SSL協(xié)議的體系結(jié)構(gòu)
SSL協(xié)議主要由兩層組成，分別是握手協(xié)議層和記錄協(xié)議層，握手協(xié)議建立在記錄協(xié)議之上，此外還有警告協(xié)議、更改密碼說明協(xié)議和應(yīng)用數(shù)據(jù)協(xié)議等對(duì)話協(xié)議和管理提供支持的子協(xié)議。其組成如圖所示：
握手協(xié)議HandshakeProtocol和記錄協(xié)議Record Protocol是SSL協(xié)議的核心組成部分。其上是超文本協(xié)議HTTP、文件傳輸協(xié)議FTP和傳輸控制協(xié)議TELNET。它們控制文本的傳輸。支撐握手、記錄協(xié)議的低層通信是用戶數(shù)據(jù)報(bào)文和TCP/IP協(xié)議。
SSL發(fā)出消息是將數(shù)據(jù)分為可管理的塊、壓縮、使用MAC和加密并發(fā)出加密的結(jié)果。接受消息需要解密、驗(yàn)證、解壓和重組，再把結(jié)果發(fā)往更高一層的客戶。以下是兩個(gè)主要協(xié)議的論述和分析。
1) 記錄協(xié)議：具體實(shí)現(xiàn)壓縮/解壓縮、加密/解密、計(jì)算機(jī)MAC等與安全有關(guān)的操作。建立之上的還有：
更改密碼說明協(xié)議：此協(xié)議由一條消息組成，可由客戶端或服務(wù)器發(fā)送，通知接收方后面的記錄將被新協(xié)商的密碼說明和密鑰保護(hù)，接收方得此消息后，立即指示記錄層把即將讀狀態(tài)變成當(dāng)前讀狀態(tài)，發(fā)送方發(fā)送此消息后，應(yīng)立即指示記錄層把即將寫狀態(tài)變成當(dāng)前寫狀態(tài)。
警告協(xié)議：警告消息傳達(dá)消息的嚴(yán)重性并描述警告。一個(gè)致命的警告將立即終止連接。與其他消息一樣，警告消息在當(dāng)前狀態(tài)下被加密和壓縮。警告消息有以下幾種：
關(guān)閉通知消息、意外消息、錯(cuò)誤記錄MAC消息、解壓失敗消息、握手失敗消息、無(wú)證書消息、錯(cuò)誤證書消息、不支持的證書消息、證書撤回消息、證收過期消息、證書未知和參數(shù)非法消息等等。
應(yīng)用數(shù)據(jù)協(xié)議：將應(yīng)用數(shù)據(jù)直接傳遞給記錄協(xié)議。
SSL記錄協(xié)議原理如圖2所示。
2) 握手協(xié)議：SSL握手協(xié)議是用來在客戶端和服務(wù)器端傳輸應(yīng)用數(shù)據(jù)而建立的安全通信機(jī)制。
―算法協(xié)商：首次通信時(shí)，雙方通過握手協(xié)議協(xié)商密鑰加密算法，包括數(shù)據(jù)加密算法和文摘算法。
―身份驗(yàn)證：在密鑰協(xié)商完成后，客戶端與服務(wù)器端通過證書交換，互相驗(yàn)證對(duì)方的身份，一般通過目錄服務(wù)器的L DAP查詢完成。
―確定密鑰：最后使用協(xié)商好的密鑰交換算法產(chǎn)生一個(gè)只有雙方知道的秘密信息，客戶端和服務(wù)器各自根據(jù)這個(gè)秘密信息確定數(shù)據(jù)加密算法的參數(shù)(一般是對(duì)稱密鑰)。
由此可見，SSL協(xié)議是端對(duì)端的通信安全協(xié)議，即數(shù)字通信安全管道。
4SSL協(xié)議的實(shí)現(xiàn)工作過程
4.1 SSL通信過程
基于OpenSSL的程序可以被分為兩個(gè)部分：客戶機(jī)和服務(wù)器，使用SSL協(xié)議使通信雙方可以相互驗(yàn)證對(duì)方身份的真實(shí)性，并且能夠保證數(shù)據(jù)的完整性和機(jī)密性。建立SSL通信的過程如圖3所示。
SSL通信模型采用標(biāo)準(zhǔn)的C/S結(jié)構(gòu)，除了在TCP層上進(jìn)行傳輸之外，與普通的網(wǎng)絡(luò)通信協(xié)議沒有太大的區(qū)別，基于OpenSSL的程序都要遵循以下幾個(gè)步驟：
1) OpenSSL初始化
在使用OpenSSL之前，必須進(jìn)行相應(yīng)的協(xié)議初始化工作，這可以通過下面的函數(shù)實(shí)現(xiàn)：
int SSL_library_int(void);
2) 選擇會(huì)話協(xié)議
在利用OpenSSL開始SSL會(huì)話之前，需要為客戶端和服務(wù)器制定本次會(huì)話采用的協(xié)議，目前能夠使用的協(xié)議包括TLSv1.0、SSLv2、SSLv3、SSLv2/v3。
需要注意的是，客戶端和服務(wù)器必須使用相互兼容的協(xié)議，否則SSL會(huì)話將無(wú)法正常進(jìn)行。
3) 創(chuàng)建會(huì)話環(huán)境
在OpenSSL中創(chuàng)建的SSL會(huì)話環(huán)境稱為CTX，使用不同的協(xié)議會(huì)話，其環(huán)境也不一樣的。申請(qǐng)SSL會(huì)話環(huán)境的OpenSSL函數(shù)是：
SSL_CTX *SSL_CTX_new(SSL_METHOD * method);
當(dāng)SSL會(huì)話環(huán)境申請(qǐng)成功后，還要根據(jù)實(shí)際的需要設(shè)置CTX的屬性，通常的設(shè)置是指定SSL握手階段證書的驗(yàn)證方式和加載自己的證書。制定證書驗(yàn)證方式的函數(shù)是：
int SSL_CTX_set_verify(SSL_CTX *ctx,int mode,int(*verify_callback),int(X509_STORE_CTX *));
為SSL會(huì)話環(huán)境加載CA證書的函數(shù)是：
SSL_CTX_load_verify_location(SSL_CTX *ctx,const char *Cafile,const char *Capath);
為SSL會(huì)話加載用戶證書的函數(shù)是：
SSL_CTX_use_certificate_file(SSL_CTX *ctx, const char *file,int type);
為SSL會(huì)話加載用戶私鑰的函數(shù)是：
SSL_CTX_use_PrivateKey_file(SSL_CTX *ctx,const char* file,int type);
在將證書和私鑰加載到SSL會(huì)話環(huán)境之后，就可以調(diào)用下面的函數(shù)來驗(yàn)證私鑰和證書是否相符：
int SSL_CTX_check_private_key(SSL_CTX *ctx);
4) 建立SSL套接字
SSL套接字是建立在普通的TCP套接字基礎(chǔ)之上，在建立SSL套接字時(shí)可以使用下面的一些函數(shù)：
SSL *SSl_new(SSL_CTX *ctx);
//申請(qǐng)一個(gè)SSL套接字
int SSL_set_fd(SSL *ssl,int fd);)
//綁定讀寫套接字
int SSL_set_rfd(SSL *ssl,int fd);
//綁定只讀套接字
int SSL_set_wfd(SSL *ssl,int fd);
//綁定只寫套接字
5) 完成SSL握手
在成功創(chuàng)建SSL套接字后，客戶端應(yīng)使用函數(shù)SSL_connect( )替代傳統(tǒng)的函數(shù)connect( )來完成握手過程:
int SSL_connect(SSL *ssl);
而對(duì)服務(wù)器來講，則應(yīng)使用函數(shù)SSL_ accept ( )替代傳統(tǒng)的函數(shù)accept ( )來完成握手過程:
int SSL_accept(SSL *ssl);
握手過程完成之后，通常需要詢問通信雙方的證書信息，以便進(jìn)行相應(yīng)的驗(yàn)證，這可以借助于下面的函數(shù)來實(shí)現(xiàn):
X509 *SSL_get_peer_certificate(SSL *ssl);
該函數(shù)可以從SSL套接字中提取對(duì)方的證書信息，這些信息已經(jīng)被SSL驗(yàn)證過了。
X509_NAME *X509_get_subject_name(X509 *a);
該函數(shù)得到證書所用者的名字。
6) 進(jìn)行數(shù)據(jù)傳輸
當(dāng)SSL握手完成之后，就可以進(jìn)行安全的數(shù)據(jù)傳輸了，在數(shù)據(jù)傳輸階段，需要使用SSL_read( )和SSL_write( )來替代傳統(tǒng)的read( )和write( )函數(shù)，來完成對(duì)套接字的讀寫操作：
int SSL_read(SSL *ssl,void *buf,int num);
int SSL_write(SSL *ssl,const void *buf,int num);
7) 結(jié)束SSL通信
當(dāng)客戶端和服務(wù)器之間的數(shù)據(jù)通信完成之后，調(diào)用下面的函數(shù)來釋放已經(jīng)申請(qǐng)的SSL資源：
int SSL_shutdown(SSL *ssl);
//關(guān)閉SSL套接字
void SSl_free(SSL *ssl);
//釋放SSL套接字
void SSL_CTX_free(SSL_CTX *ctx);
//釋放SSL會(huì)話環(huán)境
4.2 SSL握手協(xié)議的工作過程
SSL協(xié)議的工作過程主要就是握手協(xié)議的工作過程。下面我們重點(diǎn)講述握手協(xié)議的工作過程。圖4是握手協(xié)議簡(jiǎn)化的握手順序。
SSL協(xié)議具體握手過程描述如下：
―客戶Client端發(fā)送ClientHello信息給服務(wù)器Server端，Server回答ServerHello。這個(gè)過程建立的安全參數(shù)包括協(xié)議版本、“佳話”標(biāo)識(shí)、加密算法、壓縮方法。另外，還交換兩個(gè)隨機(jī)數(shù)：ClientHello.Random和ServerHello.Random.用以計(jì)算機(jī)“會(huì)話主密鑰”。
―Hello消息發(fā)送完后，Server會(huì)發(fā)送它的證書和密鑰交換信息，如果Server端被認(rèn)證，它就會(huì)請(qǐng)求Client端的證書，在驗(yàn)證以后，Server就發(fā)送H elloDone消息以示達(dá)成了握手協(xié)議，即雙方握手接通。
―Server請(qǐng)求Client證書時(shí)，Client要返回證書或返回“沒有證書的指示，這種情況用于單向認(rèn)證，即客戶端沒有裝證書，然后Client發(fā)送密鑰交換消息。
―服務(wù)器Server此時(shí)要回答“握手完成“消息(Finished)，以示完整的握手消息交換已經(jīng)全部完成。
―握手協(xié)議完成后，Client端即可與Server端傳輸應(yīng)用加密數(shù)據(jù)，應(yīng)用數(shù)據(jù)加密一般是用第②步密鑰協(xié)商時(shí)確定的對(duì)稱加/解密密鑰，如DE S、3DE等等，目前商用加密強(qiáng)度為128位。非對(duì)稱密鑰一般為RAS，商用強(qiáng)度1024位，用于證書的驗(yàn)證。
5 總結(jié)
SSL協(xié)議很好的解決了Internet上信息的安全傳輸，彌補(bǔ)了TCP/IP協(xié)議的不足，使得我們?cè)诰W(wǎng)絡(luò)上傳輸數(shù)據(jù)得到安全保障。SSL協(xié)議雖然得到了廣泛的應(yīng)用，但是它也存在了很多不足。SSL協(xié)議中引入了很多安全機(jī)制，如非對(duì)稱密鑰交換、數(shù)據(jù)加密、消息認(rèn)證碼MAC、身份認(rèn)證等，因?yàn)橛靡员Ｗo(hù)數(shù)據(jù)的所有加密密鑰都是通過masterSecret來產(chǎn)生的，故協(xié)議的所有安全幾乎都依賴于masterSecret的保密，如果某個(gè)會(huì)話的masetrSecert被攻破的話，這個(gè)會(huì)話就會(huì)完全暴露于攻擊之下。而且SSL協(xié)議不提供交易的不可抵賴性。對(duì)于電子商務(wù)應(yīng)用來說，使用SSL可保證信息的真實(shí)性、完整性和保密性。但由于SSL不對(duì)應(yīng)用層的消息進(jìn)行數(shù)字簽名，因此不能提供交易的不可否認(rèn)性，這是 SSL在電子商務(wù)中使用的最大不足。有鑒于此，網(wǎng)景公司在從Communicator 4.04版開始的所有瀏覽器中引入了一種被稱作"表單簽名（Form Signing）"的功能，在電子商務(wù)中，可利用這一功能來對(duì)包含購(gòu)買者的訂購(gòu)信息和付款指令的表單進(jìn)行數(shù)字簽名，從而保證交易信息的不可否認(rèn)性。綜上所述，在電子商務(wù)中采用單一的SSL協(xié)議來保證交易的安全是不夠的，但采用"SSL+表單簽名"模式能夠提供較好的安全性保證。
參考文獻(xiàn)：
[1] 顧兵.VPN技術(shù)在企業(yè)中的應(yīng)用[J].中國(guó)海洋平臺(tái),2003(1)：44-46.
[2] 懂洪偉,馮斌,楊開蕎.VPN關(guān)鍵技術(shù)探討[J].計(jì)算機(jī)工程,2002(11):159-161,177.
篇2
一、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):
篇3
解決方法：
篇4
Internet payment system based on SSL and SET protocol
JIANG Zhihua
(Info. Eng. College, Shanghai Maritime Univ., Shanghai 200135, China)
Abstract： Internet payment is the bottleneck that restricts the development of E-Business. So the general internet payment system framework for bank card is introduced, and an Internet payment system based on Secure Socket Layer (SSL) and Secure Electronic Transaction (SET) protocol is proposed. And its payment flow and security are detailed and discussed.
Key words： Internet payment; secure socket layer; secure electronic transaction; E-Business; payment system; E-Wallet
0 引 言
網(wǎng)絡(luò)支付方式是電子商務(wù)發(fā)展的關(guān)鍵要素.電子商務(wù)交易支付涉及支付安全和實(shí)現(xiàn)平臺(tái)的統(tǒng)一，信息安全技術(shù)已經(jīng)為網(wǎng)絡(luò)支付研究出一系列安全加密及信息傳輸?shù)募夹g(shù)規(guī)范，如以安全套接層(Secure Socket Layer, SSL)協(xié)議和安全電子交易協(xié)議(Secure Electronic Transaction, SET)為代表的網(wǎng)絡(luò)支付協(xié)議及應(yīng)用于網(wǎng)上的數(shù)字簽名、用戶論證等技術(shù).本文結(jié)合SSL和SET網(wǎng)絡(luò)支付協(xié)議及應(yīng)用技術(shù)，討論基于第三方運(yùn)營(yíng)的網(wǎng)絡(luò)支付方式，發(fā)揮SET的嚴(yán)密性和SSL的簡(jiǎn)單直觀性等特點(diǎn)，使網(wǎng)絡(luò)支付系統(tǒng)構(gòu)建體現(xiàn)資源整合、方便交易特色的統(tǒng)一支付平臺(tái).
1 網(wǎng)絡(luò)支付模式
網(wǎng)絡(luò)支付是指電子商務(wù)交易的當(dāng)事人，包括消費(fèi)者、廠商和金融機(jī)構(gòu)，使用安全電子支付手段通過網(wǎng)絡(luò)進(jìn)行的貨幣支付或資金流轉(zhuǎn)，對(duì)支付的要求是能夠?qū)崿F(xiàn)跨地跨行的交易支付快捷且安全，并保證銀行之間、銀行商戶之間的資金結(jié)算準(zhǔn)確無(wú)誤.電子支付的方式主要有3類：一類是電子貨幣類，如電子現(xiàn)金和電子錢包等；另一類是電子信用卡類，包括銀行磁卡、智能卡和電話卡等；還有一類是電子支票類，如電子支票、電子匯款和電子劃款等.
在電子支付的3種基本支付方式中信用卡（銀行卡）支付得到世界范圍內(nèi)的普及［1］，能很好地解決小額在線支付結(jié)算中的安全問題，因此越來越多的人愿意接受并且喜歡利用信用卡進(jìn)行網(wǎng)絡(luò)支付.信用卡網(wǎng)絡(luò)支付模式總體有下面4種.
1.1 無(wú)安全措施的信用卡支付模式
這種支付模式是指持卡人利用信用卡進(jìn)行支付結(jié)算時(shí)，幾乎沒有采取任何技術(shù)上的安全措施而把信用卡號(hào)碼和密碼直接傳送給商家，然后由商家負(fù)責(zé)后續(xù)處理的模式(見圖1).這是在電子商務(wù)發(fā)展初期各方面都不太成熟，特別是銀行對(duì)電子商務(wù)的支持還不完善的情況下出現(xiàn)的，風(fēng)險(xiǎn)由商家負(fù)責(zé)，安全性差，持卡人的信用卡隱私信息完全被商家掌握，支付效率較低.［2］
1.2 借助第三方機(jī)構(gòu)的信用卡支付模式
為了降低在無(wú)安全措施支付模式中的風(fēng)險(xiǎn)，在買方和賣方之間啟用1個(gè)具有誠(chéng)信的第三方機(jī)構(gòu)，這個(gè)機(jī)構(gòu)持有持卡客戶的信用卡賬號(hào)信息用于與銀行的支付結(jié)算，并負(fù)責(zé)將交易信息在商家和客戶之間傳遞(見圖2).這種方式對(duì)第三方機(jī)構(gòu)的公正、信譽(yù)和操作規(guī)范有很高的要求［3］，主要風(fēng)險(xiǎn)由第三方機(jī)構(gòu)承擔(dān)，安全性得到一定的保證；但由于并未發(fā)揮銀行網(wǎng)絡(luò)在支付中的作用，在提高安全性的同時(shí)支付效率沒有得到提高，成本也較高，且不太適合小額的網(wǎng)上支付.
1.3 基于SSL協(xié)議機(jī)制的信用卡支付模式
這種方式為Internet環(huán)境下信用卡支付的典型方式(見圖3)：使用SSL作為安全會(huì)話，保護(hù)和防止Internet其他用戶獲取信用卡帳號(hào)等機(jī)密信息.交易多方身份驗(yàn)證機(jī)構(gòu)認(rèn)證中心(Certification Authority,CA)的作用是間接的，主要是為支付各方頒發(fā)證書.用戶以明文方式輸入其信用卡號(hào)，該卡號(hào)將被加過密的SSL會(huì)話發(fā)送給商家的服務(wù)器并轉(zhuǎn)發(fā)給發(fā)卡銀行.這種通過商家中轉(zhuǎn)支付信息的SSL支付模式不能保證支付賬戶信息不被商家看到，所以改進(jìn)的SSL支付模式就是客戶瀏覽器與銀行服務(wù)器之間直接建立SSL加密聯(lián)接.SSL支付模式是應(yīng)用最為廣泛的網(wǎng)絡(luò)支付模式，其特點(diǎn)是應(yīng)用方便、成本較低、安全性高、市場(chǎng)產(chǎn)品成熟，國(guó)內(nèi)大多數(shù)商業(yè)銀行的信用卡網(wǎng)絡(luò)支付系統(tǒng)都采用這種技術(shù)模式，絕大多數(shù)的網(wǎng)上商家均支持這種模式的信用卡應(yīng)用.
SET協(xié)議是由Visa和MasterCard聯(lián)合開發(fā)的1種開放性標(biāo)準(zhǔn).SET協(xié)議可以讓持卡人在開放網(wǎng)絡(luò)上發(fā)送安全的支付指令和獲取認(rèn)證信息.SET主要用于兼容當(dāng)前的信用卡網(wǎng)絡(luò)，目前涉及的是B2C的電子商務(wù)交易.在交易之前，客戶必須到相應(yīng)的發(fā)卡銀行柜臺(tái)辦理應(yīng)用SET協(xié)議機(jī)制的信用卡，并下載安裝持卡客戶端軟件（電子錢包軟件），將信用卡相關(guān)信息添加進(jìn)客戶端軟件，最后為其中的信用卡申請(qǐng)數(shù)字證書；同樣，商戶需到銀行辦理這類信用卡結(jié)算事宜，得到服務(wù)器端SET支持軟件，并且從CA得到數(shù)字證書.作為銀行網(wǎng)絡(luò)與外部網(wǎng)的接口支付網(wǎng)關(guān)，也須得到數(shù)字證書的認(rèn)證.在交易過程中，SET介入信用卡支付的全過程，由于加密、認(rèn)證較多，支付處理速度相對(duì)SSL機(jī)制的信用卡支付稍慢，各方開銷也大一些，但該協(xié)議設(shè)計(jì)得很安全，已經(jīng)成為事實(shí)上的工業(yè)標(biāo)準(zhǔn).［4］
2 基于SSL和SET的網(wǎng)絡(luò)支付
2.1 網(wǎng)絡(luò)支付原理
目前應(yīng)用較多的SSL和SET機(jī)制各有優(yōu)劣.SSL強(qiáng)調(diào)的重點(diǎn)在于實(shí)現(xiàn)網(wǎng)絡(luò)支付的便捷性，即可以在任何1網(wǎng)的PC上進(jìn)行網(wǎng)上支付（需要安全認(rèn)證和數(shù)字證書的下載），但是用戶必須遵循不同銀行卡相對(duì)獨(dú)立的支付規(guī)則，且針對(duì)銀行的是特約商戶，一般商戶不能支持所有銀行卡.而SET流程設(shè)計(jì)安全，一般利用安裝在物理設(shè)備（用戶PC硬盤）之上的電子錢包模擬實(shí)際購(gòu)物，對(duì)于用戶而言很直觀也比較易用，但是移動(dòng)性卻因?yàn)樾枰惭b電子錢包軟件而喪失，每次網(wǎng)絡(luò)支付都要安裝電子錢包軟件很不現(xiàn)實(shí).
結(jié)合SSL和SET網(wǎng)上支付的優(yōu)勢(shì)，將安裝在本地硬盤的電子錢包置于網(wǎng)絡(luò)上，由獨(dú)立的第三方（網(wǎng)絡(luò)服務(wù)商）管理用戶電子錢包，并使網(wǎng)上錢包與銀行的前端接口――支付網(wǎng)關(guān)有機(jī)結(jié)合，這樣用戶在網(wǎng)上購(gòu)物與支付時(shí)，以瀏覽器加密專用通道（即SSL）的方式使用SET機(jī)制的電子錢包功能.
2.2 網(wǎng)絡(luò)支付流程
網(wǎng)絡(luò)支付流程見圖4.
從圖4可知，利用網(wǎng)上錢包進(jìn)行在線支付的大致流程如下：（1）申請(qǐng)電子錢包.客戶要在網(wǎng)上錢包服務(wù)商處開通網(wǎng)上錢包功能，申請(qǐng)電子錢包并進(jìn)行設(shè)置.一般情況下客戶可以到柜臺(tái)申請(qǐng)，也可以在線申請(qǐng)，成功后用戶得到網(wǎng)上錢包的賬號(hào)和密碼.用戶還需對(duì)自己的電子錢包進(jìn)行設(shè)置，將信用卡及支付卡賬號(hào)、密碼等信息存入網(wǎng)上錢包的個(gè)人賬戶中，除此之外還應(yīng)對(duì)電子錢包的保密性做設(shè)置.（2）使用錢包中的信用卡支付.網(wǎng)上錢包實(shí)際上是個(gè)統(tǒng)一的支付平臺(tái)，用戶在SSL會(huì)話界面輸入自己的網(wǎng)上錢包賬號(hào)和密碼進(jìn)入錢包系統(tǒng)，選擇信用卡進(jìn)行支付.此時(shí)SET介入其中，對(duì)于銀行支付網(wǎng)關(guān)，可以是與網(wǎng)上錢包平臺(tái)集成的統(tǒng)一支付網(wǎng)關(guān)，也可以是銀行自身的支付網(wǎng)關(guān).收單行扣款成功返還給網(wǎng)上錢包平臺(tái)，再通過SSL通知客戶支付成功信息.
3 網(wǎng)絡(luò)支付的安全性討論
網(wǎng)絡(luò)支付給用戶帶來使用上的方便，而且SSL和SET的結(jié)合能夠使支付交易的速度得到提高.SSL和SET協(xié)議在網(wǎng)絡(luò)安全上根據(jù)不同的安全要求和級(jí)別采取相應(yīng)的安全防范措施.同樣，網(wǎng)絡(luò)支付在應(yīng)用中也采用諸如數(shù)字簽名、數(shù)字信封和數(shù)字摘要等技術(shù)，使其安全性問題就在于第三方錢包運(yùn)營(yíng)商的公正性（如錢包用戶基本信息的保密問題等）以及錢包用戶身份合法性上.
前者應(yīng)當(dāng)強(qiáng)化第三方機(jī)構(gòu)（服務(wù)商）的審核，可以在應(yīng)用中由業(yè)界普遍認(rèn)同的絕對(duì)公正的金融機(jī)構(gòu)擔(dān)任網(wǎng)上錢包的服務(wù)商，同時(shí)CA應(yīng)適時(shí)地加以身份鑒證；技術(shù)上加強(qiáng)用戶對(duì)錢包賬戶信息的自我控制，對(duì)錢包運(yùn)營(yíng)商的數(shù)據(jù)監(jiān)控.對(duì)于后者［5］，應(yīng)加強(qiáng)密碼系統(tǒng)的安全性，用戶應(yīng)注意賬戶信息的保密和密碼的及時(shí)更新，必要時(shí)可以采用動(dòng)態(tài)密碼機(jī)制.另外將賬戶信息集成在存儲(chǔ)設(shè)備（如智能卡）上，采用雙重身份登陸方法，也是實(shí)現(xiàn)網(wǎng)上錢包個(gè)人安全登陸的好辦法.目前，國(guó)內(nèi)金融網(wǎng)絡(luò)建設(shè)的“銀聯(lián)”模式就是這樣的實(shí)際應(yīng)用，“銀聯(lián)”是依托于銀行卡跨行跨地的資金流轉(zhuǎn)業(yè)務(wù)而產(chǎn)生的，除了提供銀行卡方便的現(xiàn)金支取和消費(fèi)刷卡之外，其技術(shù)優(yōu)勢(shì)可完全應(yīng)用于網(wǎng)絡(luò)支付，作為第三方的支付網(wǎng)關(guān)，代表眾多商業(yè)銀行的支付工具，已經(jīng)實(shí)現(xiàn)在線支付的即時(shí)到賬，各類具有銀聯(lián)標(biāo)志的銀行卡都能方便地完成網(wǎng)絡(luò)支付，并且正得到越來越多的應(yīng)用.
4 結(jié) 論
本文闡述的是基于SSL和SET相結(jié)合的網(wǎng)絡(luò)支付系統(tǒng)，是權(quán)衡兩者利弊的較佳方案.可以看到，網(wǎng)絡(luò)支付依托的是傳統(tǒng)的網(wǎng)絡(luò)支付模型和工具，在系統(tǒng)構(gòu)成上主要要素不變，這就說明已經(jīng)成熟的網(wǎng)絡(luò)支付協(xié)議及安全技術(shù)是支付系統(tǒng)的基礎(chǔ)，而在支付方式的形式上有比較大的拓展空間，這要根據(jù)實(shí)際的支付環(huán)境來決定.在設(shè)計(jì)網(wǎng)絡(luò)支付系統(tǒng)時(shí)，應(yīng)充分考慮支付環(huán)境和交易的情況，做到安全和便捷的統(tǒng)一.
參考文獻(xiàn)：
［1］ 梁春曉, 安徽. 電子商務(wù)從理念到行動(dòng)［M］. 北京: 清華大學(xué)出版社, 2001.
［2］ 柯新生. 網(wǎng)絡(luò)支付與結(jié)算［M］. 北京: 電子工業(yè)出版社, 2004.
篇5
隨著計(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)證，無(wú)法適應(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無(wú)法避免通信業(yè)務(wù)流分析攻擊。由于SSL位于TCP/IP的協(xié)議層之上，因此，無(wú)法對(duì)TCP/IP協(xié)議頭部進(jìn)行保護(hù)，導(dǎo)致潛在的隱患。攻擊者通過獲取IP地址、URL請(qǐng)求的長(zhǎng)度以及返回的Web頁(yè)面的長(zhǎng)度等信息，可以分析出用戶訪問的目標(biāo)，再加上SSL協(xié)議只支持對(duì) 塊密碼的隨機(jī)填充，沒有提供對(duì)流式密碼算法的支持，使得SSL無(wú)法阻止這類攻擊。
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)：
篇6
SSL Protocol in the Network Communication of the Application
ZHANG Yang
(Liaoning University Computing Center, Shenyang 110036, China)
Abstract: SSL protocol is to provide a secure channel between computers a security protocol, data transmission is encrypted. This article has wireless video surveillance system for the study, the introduction of the SSL protocol in the system, the application of the protocol on the server and the client’s network communication, which can achieve data transmission security, authentication and message integrity.
Key words: SSL protocol; information security; network communication
無(wú)線視頻監(jiān)控系統(tǒng)服務(wù)器和客戶端之間采用的C/S模式組成的，實(shí)現(xiàn)對(duì)視頻信號(hào)實(shí)時(shí)采集和壓縮編碼后，將圖像傳輸?shù)街付ǖ囊曨l服務(wù)器上。那么命令信息在傳輸過程中，數(shù)據(jù)的安全性是我們需要解決的重要問題。所以在該系統(tǒng)中引入了SSL協(xié)議，把SSL協(xié)議應(yīng)用在服務(wù)器和客戶端的網(wǎng)絡(luò)通信中，通過數(shù)據(jù)加密提高信息的安全性。
1系統(tǒng)設(shè)計(jì)原則和目標(biāo)
1.1系統(tǒng)設(shè)計(jì)原則
該系統(tǒng)的服務(wù)器和客戶端都是在windows操作系統(tǒng)利用VC的socket建立連接，實(shí)現(xiàn)網(wǎng)絡(luò)通信。考慮到服務(wù)器和客戶端之間數(shù)據(jù)傳輸?shù)陌踩院陀行裕O(shè)計(jì)過程中注意以下幾個(gè)方面：
1）并發(fā)性：因?yàn)榉?wù)器和客戶端之間建立聯(lián)系，一般是一臺(tái)服務(wù)器對(duì)應(yīng)多個(gè)客戶端進(jìn)行通信的，每個(gè)終端優(yōu)先級(jí)是平等的，為了實(shí)現(xiàn)客戶端的并發(fā)，在服務(wù)器端采用VC中的多線程技術(shù)，使得每個(gè)客戶端都能和服務(wù)器同時(shí)產(chǎn)生通信。
2）安全性：該系統(tǒng)是服務(wù)器和客戶端之間利用socket通信，客戶端向服務(wù)器發(fā)送請(qǐng)求命令，服務(wù)器收到后回應(yīng)請(qǐng)求，如果在通信過程中命令信息不加密，信息容易被非法竊取，直接通過TCP協(xié)議傳輸信息是不安全的，所以要引入SSL協(xié)議，使所有的命令信息是加密傳輸?shù)模ＷC了信息的安全性。
3）實(shí)時(shí)性：由于視頻監(jiān)控系統(tǒng)對(duì)畫面的實(shí)時(shí)性要求非常高的，如果圖像也是通過加密傳輸?shù)脑挘瑫?huì)嚴(yán)重影響圖像的傳輸速率，也就失去了實(shí)時(shí)性的要求，所以，我們?cè)谔幚韴D像傳輸時(shí)就不像命令信息一樣通過SSL加密傳輸了，滿足了圖像的實(shí)時(shí)性要求。1.2系統(tǒng)設(shè)計(jì)的目標(biāo)
該系統(tǒng)實(shí)現(xiàn)的目標(biāo)就是服務(wù)器端和客戶端建立連接，滿足并發(fā)性的要求；在通信過程中，雙方發(fā)送的命令信息通過SSL加密傳輸，提高安全性；圖像傳輸通過TCP協(xié)議傳輸，滿足視頻傳輸?shù)膶?shí)時(shí)性。
2網(wǎng)絡(luò)通信模塊的設(shè)計(jì)
主要討論的是服務(wù)器和客戶端之間的網(wǎng)絡(luò)通信問題，服務(wù)器和客戶端之間有兩種信息:服務(wù)器向客戶端轉(zhuǎn)發(fā)的視頻流信息；服務(wù)器和客戶端之間傳輸?shù)拿钚畔ⅰ男畔⒌陌踩钥紤]，在該系統(tǒng)中引入SSL加密協(xié)議，在數(shù)據(jù)傳輸過程中，即使數(shù)據(jù)被黑客竊取也不會(huì)將數(shù)據(jù)還原。確保了數(shù)據(jù)的安全性。
因?yàn)楸O(jiān)控視頻對(duì)圖像的實(shí)時(shí)性要求非常高，不能有太長(zhǎng)的時(shí)間延遲，而視頻在傳輸過程中產(chǎn)生的流量非常之大，直接通過TCP協(xié)議傳輸視頻信息可以有效降低時(shí)間延遲。
因此，通過SSL協(xié)議傳輸各種命令信息，我們可以把SSL通信模塊封裝成sslclient類和sslserver類，提供了接口函數(shù)，只需要調(diào)用對(duì)應(yīng)的API就可以實(shí)現(xiàn)SSL加密通信。
3 SSL網(wǎng)絡(luò)通信技術(shù)的實(shí)現(xiàn)
3.1 SSL通信模塊的工作流程
該系統(tǒng)的整個(gè)結(jié)構(gòu)可以分為服務(wù)器和客戶端兩個(gè)部分組成，而其中的SSL通信模塊為現(xiàn)實(shí)這兩個(gè)部分之間的數(shù)據(jù)通信的安全傳輸提供服務(wù)。主要從外部和內(nèi)部?jī)蓚€(gè)方面來分析，從外部來看，系統(tǒng)包括初始化握手部分和數(shù)據(jù)傳輸部分兩個(gè)部分內(nèi)容，這兩個(gè)部分的內(nèi)容具體對(duì)應(yīng)SSL協(xié)議的“握手協(xié)議”和“記錄協(xié)議”。從內(nèi)部來看，SSL模塊可劃分為初始化、SSL連接、身份認(rèn)證和數(shù)據(jù)傳輸幾個(gè)模塊，初始化主要為SSL連接做準(zhǔn)備工作，身份認(rèn)證主要是驗(yàn)證對(duì)方數(shù)字證書以證明身份的有效性。如果服務(wù)器也要求進(jìn)行客戶端身份認(rèn)證，會(huì)以同樣的方法對(duì)客戶端的證書進(jìn)行驗(yàn)證。當(dāng)服務(wù)器和客戶端互相進(jìn)行驗(yàn)證之后。會(huì)在兩者之間成功建立SSL連接，形成一個(gè)安全數(shù)據(jù)傳輸通道，傳輸數(shù)據(jù)類似于TCP的套接字，直接寫入或者讀取數(shù)據(jù)。如圖1所示。
圖1 SSL通信模塊的結(jié)構(gòu)圖
3.2實(shí)現(xiàn)的過程
在通信模塊中，服務(wù)器實(shí)現(xiàn)的過程很簡(jiǎn)單，和客戶端實(shí)現(xiàn)的過程類似，服務(wù)器等待客戶端發(fā)送請(qǐng)求的連接，之后初始化一條SSL連接，它就從客戶端讀取或?qū)懭霐?shù)據(jù)發(fā)送到客戶端。按照功能也可以分為四部分：初始化過程、連接過程、身份認(rèn)證過程和數(shù)據(jù)傳輸。
1）初始化過程：客戶端的開發(fā)時(shí)調(diào)用openssl函數(shù)實(shí)現(xiàn)的，首先是初始化SSL庫(kù)，在選擇會(huì)話連接所使用的協(xié)議：ssl_method* sslv3_client_method();再去申請(qǐng)SSL會(huì)話的CTX:ssl_ctx* ssl_ctx_new(ssl_method* meth);，目的是連接對(duì)象進(jìn)行SSL握手、數(shù)據(jù)的讀寫；最后是家在私有密鑰和數(shù)字證書并設(shè)置加密套件。
然而服務(wù)器初始化過程和客戶端初始化過程類似，不同只是服務(wù)器調(diào)用sslv3_server_method()函數(shù)來實(shí)現(xiàn)的。
2）連接過程：服務(wù)器調(diào)用listen函數(shù)開始監(jiān)聽客戶端的TCP連接請(qǐng)求，調(diào)用accept函數(shù)接受客戶端的TCP連接；申請(qǐng)一個(gè)BIO對(duì)象，把SSL綁在在這個(gè)對(duì)象上；調(diào)用SSL的accept函數(shù)接受客戶端的SSL連接。
3）身份認(rèn)證：由于系統(tǒng)采用雙向身份認(rèn)證機(jī)制進(jìn)行身份認(rèn)證，所以服務(wù)器和客戶端的證書都要互相進(jìn)行認(rèn)證方可正常通信，二者進(jìn)行信息對(duì)比，如果一致，表明驗(yàn)證通過，否則將關(guān)閉與客戶端之間的連接。
4）數(shù)據(jù)傳輸：服務(wù)器與客戶端建立連接后就可傳輸數(shù)據(jù)，所有數(shù)據(jù)是經(jīng)SS加密處理后進(jìn)行傳輸?shù)摹?/p>
4結(jié)束語(yǔ)
在當(dāng)今信息化飛速發(fā)展的社會(huì)中，信息數(shù)據(jù)在日常生活和工作中顯得越來越重要，所以信息安全的重要性也越來越受到人們的重視，數(shù)據(jù)在保存和傳輸過程中如何可以防止黑客竊取，正是該文研究的對(duì)象。該文以視頻監(jiān)控作為實(shí)例來研究，既要保證視頻傳輸?shù)膶?shí)時(shí)性，又要保障數(shù)據(jù)的安全性，所以我們采用服務(wù)器和客戶端之間采用靈活的雙重連接制，通過SSL協(xié)議進(jìn)行數(shù)據(jù)加密傳輸，提高了機(jī)密信息傳輸?shù)陌踩浴?/p>
參考文獻(xiàn)：
[1]付沙,何誠(chéng),文旭華.基于SSL協(xié)議的安全網(wǎng)絡(luò)通信的理論和實(shí)現(xiàn)[J].計(jì)算機(jī)與現(xiàn)代,2006(11).
[2]曾強(qiáng).網(wǎng)絡(luò)安全協(xié)議SSL原理及應(yīng)用[D].天津:天津大學(xué),2005.
[3]唐玲.數(shù)字證書系統(tǒng)的設(shè)計(jì)研究[D].合肥:合肥工業(yè)大學(xué),2004.
[4]韓澄宗.網(wǎng)絡(luò)實(shí)驗(yàn)室中的視頻監(jiān)控系統(tǒng)[D].杭州:浙江大學(xué),2006.
篇7
隨著當(dāng)前各類高校及高職學(xué)校的校園網(wǎng)建設(shè)并投入使用，校園網(wǎng)的各種信息資源需要通過網(wǎng)絡(luò)為身處不同地點(diǎn)的教師、學(xué)生及員工共享使用。當(dāng)前許多高職院校均存在多個(gè)校區(qū)的網(wǎng)絡(luò)構(gòu)架，僅通過互聯(lián)網(wǎng)絡(luò)實(shí)現(xiàn)網(wǎng)絡(luò)的聯(lián)接，顯然會(huì)存在較多的隱患，畢竟互聯(lián)網(wǎng)是一個(gè)開放的使用TCP/IP技術(shù)實(shí)現(xiàn)網(wǎng)絡(luò)連接和不可管理的互聯(lián)網(wǎng)絡(luò)。因此，如何解決位于不同校區(qū)的網(wǎng)絡(luò)基礎(chǔ)設(shè)施有可能互不兼容子網(wǎng)絡(luò)實(shí)現(xiàn)安全的互聯(lián)互通成為一個(gè)較為突出的難題。而這些在其他各類網(wǎng)絡(luò)互聯(lián)中的難題催生了VPN技術(shù)的出現(xiàn)。
1 VPN技術(shù)分類
VPN（virtual private network）技術(shù)是指利用網(wǎng)絡(luò)資源臨時(shí)建立一個(gè)安全的網(wǎng)絡(luò)連接，或特定的網(wǎng)絡(luò)通道將網(wǎng)絡(luò)中物理上分布于不同區(qū)域的局域網(wǎng)絡(luò)連接成為一個(gè)邏輯上的專門網(wǎng)絡(luò)，一般VPN技術(shù)采用隧道技術(shù)、身份認(rèn)證技術(shù)、數(shù)據(jù)加密技術(shù)以及密鑰管理等關(guān)鍵技術(shù)來實(shí)施網(wǎng)絡(luò)通信的數(shù)據(jù)安全性保護(hù)。
VPN技術(shù)根據(jù)實(shí)現(xiàn)技術(shù)的不同一般可以分為PPTP、L2TP、MPLS、IPSec、SSL等，其中，基于SSL協(xié)議的VPN技術(shù)是目前應(yīng)用最為廣泛的一種VPN技術(shù)。
2 基于SSL協(xié)議的VPN技術(shù)
一般來說，SSL協(xié)議是在客戶端和服務(wù)器端之間建立安全通道的一種協(xié)議，該協(xié)議對(duì)通信雙方身份進(jìn)行認(rèn)證同時(shí)對(duì)傳輸?shù)臄?shù)據(jù)進(jìn)行保護(hù)。SSL協(xié)議通常是建立在如TCP協(xié)議這樣的可靠的傳輸層協(xié)議之上，同時(shí)獨(dú)立于應(yīng)用層協(xié)議。高層的應(yīng)用協(xié)議HTTP、FTP大多可透明地運(yùn)行于SSL協(xié)議之上。
1）SSLVPN的實(shí)現(xiàn)原理。SSLVPN是一種數(shù)據(jù)包封裝技術(shù)，一般采用SSL/TLS協(xié)議與加密算法、身份認(rèn)證技術(shù)等構(gòu)建VPN。雖然SSL協(xié)議不是為實(shí)現(xiàn)VPN而設(shè)計(jì)的，但SSL對(duì)VPN實(shí)現(xiàn)所需的數(shù)據(jù)加密、身份認(rèn)證和密鑰管理等提供了必要的技術(shù)支持。
在實(shí)現(xiàn)過程中，用戶通過瀏覽器內(nèi)建的Secure SocketLayer封包處理功能，連回到網(wǎng)絡(luò)內(nèi)部的SSLVPN服務(wù)器，采用網(wǎng)絡(luò)封包轉(zhuǎn)向的方式，讓用戶在遠(yuǎn)程計(jì)算機(jī)執(zhí)行應(yīng)用程序，讀取網(wǎng)絡(luò)內(nèi)部服務(wù)器數(shù)據(jù)。SSLVPN一般采用標(biāo)準(zhǔn)的安全套接層（SSL）對(duì)數(shù)據(jù)進(jìn)行加密，在應(yīng)用層上保護(hù)數(shù)據(jù)的安全性。SSLVPN技術(shù)可實(shí)現(xiàn)用戶安全的進(jìn)行內(nèi)部網(wǎng)絡(luò)的訪問。
2）SSLVPN的特點(diǎn)
其客戶端支撐維護(hù)簡(jiǎn)單，大多基于SSL協(xié)議的遠(yuǎn)程訪問不需要在遠(yuǎn)程客戶端上安裝軟件就可以通過Web瀏覽器訪問到企業(yè)內(nèi)部的網(wǎng)絡(luò)資源；還可以實(shí)現(xiàn)遠(yuǎn)程安全接入，通常在網(wǎng)絡(luò)防火墻后設(shè)置一個(gè)SSL服務(wù)器在用戶通過瀏覽器上輸入U(xiǎn)RL后，該連接通過SSL服務(wù)器進(jìn)用戶身份驗(yàn)證后映射到相應(yīng)的應(yīng)用服務(wù)器上實(shí)現(xiàn)遠(yuǎn)程安全接入；SSLVPN還可對(duì)加密隧道進(jìn)行細(xì)分，讓網(wǎng)絡(luò)用戶不僅可接入互聯(lián)網(wǎng)還可訪問內(nèi)部資源；SSLVPN還可穿越NAT和防火墻設(shè)備；能夠較好地抵御外部系統(tǒng)和病毒攻擊；在網(wǎng)絡(luò)部署上靈活方便，因?yàn)镾SLVPN一般部署在內(nèi)網(wǎng)中防火墻之后，可以隨時(shí)根據(jù)需要，添加需要VPN保護(hù)的服務(wù)器，不影響原有網(wǎng)絡(luò)結(jié)構(gòu)。
當(dāng)然，SSLVPN技術(shù)也存在其認(rèn)證方式僅有通過相應(yīng)的證書來進(jìn)行單向認(rèn)證的不足之處。
3 SSL VPN在多校區(qū)校園網(wǎng)中的應(yīng)用
多校區(qū)校園網(wǎng)一般是由于當(dāng)前同于區(qū)域內(nèi)的多所職業(yè)院校進(jìn)行合并后形成的特色，一般校區(qū)分布在不同行政區(qū)域，有多個(gè)獨(dú)立的校區(qū)，校區(qū)之間地理位置上不接壤等，一般為了實(shí)現(xiàn)幾個(gè)校區(qū)之間的互聯(lián)，多采用租用當(dāng)?shù)赝ㄐ胚\(yùn)行商的光線實(shí)現(xiàn)網(wǎng)絡(luò)互聯(lián)。
在此類校園網(wǎng)絡(luò)中，其網(wǎng)絡(luò)數(shù)據(jù)資源如電子圖書館必須要根據(jù)電子版權(quán)的有關(guān)版權(quán)保護(hù)規(guī)定通過安全和加密技術(shù)控制分發(fā)內(nèi)容和途徑，以防止非法的使用。在高職院校中多數(shù)電子資源都存在IP訪問限制，其數(shù)據(jù)庫(kù)資源多在資源提供商的服務(wù)器上。服務(wù)商一般采用訪問者的IP地址認(rèn)證來確認(rèn)授權(quán)的用戶的使用。因此校內(nèi)的IP都可方便的使用相應(yīng)資源，而校外的合法用戶，由于在網(wǎng)絡(luò)外部，其IP都不在范圍內(nèi)，就使得他們無(wú)法瀏覽所需的網(wǎng)絡(luò)資源，這是一種可管理、可認(rèn)證、安全的遠(yuǎn)程訪問校園內(nèi)部資源的解決方案， SSLVPN方案就解決了校外網(wǎng)用戶訪問校內(nèi)網(wǎng)的數(shù)字資源的問題。同時(shí)，SSLVPN也極大的方便校園網(wǎng)中的應(yīng)用理人員對(duì)設(shè)備的管理，對(duì)于一些簡(jiǎn)單的網(wǎng)絡(luò)或資源故障，管理人員可以通過SSLVPN對(duì)相應(yīng)的設(shè)備進(jìn)行操作實(shí)現(xiàn)故障排除。并且SSLVPN在連接時(shí)采用了安全認(rèn)證，也保證了數(shù)據(jù)傳輸時(shí)的安全。
總之，VPN技術(shù)使得未來網(wǎng)絡(luò)中基于WEB訪問的網(wǎng)絡(luò)資源運(yùn)行模式起到了極大的促進(jìn)作用，其中SSLVPN技術(shù)也由于大量移動(dòng)網(wǎng)絡(luò)的應(yīng)用而得以廣泛的應(yīng)用。
參考文獻(xiàn)：
[1] 馬淑文.SSL VPN技術(shù)在校園網(wǎng)中的應(yīng)用與研究[J].計(jì)算機(jī)工程與設(shè)計(jì)，2008（11）：5137-5143.
[2] 陽(yáng)富民，劉軍平.統(tǒng)一認(rèn)證技術(shù)研究與實(shí)現(xiàn)[J].計(jì)算機(jī)工程與科學(xué)， 2007，29（2）：124-126.
[3] 奧尼爾，冉曉旻.Web服務(wù)安全技術(shù)與原理[M].北京：清華大學(xué)出版社，2003.
[4] 戴宗坤，唐三平.VPN與網(wǎng)絡(luò)安全[M].北京：電子工業(yè)出版社，2002.
篇8
文獻(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)證過程。客戶端發(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é)語(yǔ)
為了研究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)證流程分析。基于Blanchet演算對(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áng).基于優(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.
篇9
一、Modbus RTU協(xié)議與S7-200相互關(guān)系簡(jiǎn)介
目前支持Modbus通信的DCS、PLC系統(tǒng)和過程儀表大都采用基于串行接口的Modbus RTU模式，西門子公司提供了針對(duì)西門子PLC Modbus RTU的協(xié)議庫(kù)。極大的簡(jiǎn)化了Modbus RTU通信的開發(fā)，以便快速實(shí)現(xiàn)二者的相關(guān)應(yīng)用。通過Modbus RTU從站指令庫(kù)，使得S7-200可以作為Modbus RTU中的從站，以實(shí)現(xiàn)與Modbus主站設(shè)備的通信。
二、軟硬件準(zhǔn)備
1.軟件：ModScan測(cè)試軟件、Step7-MicroWin V4.0SP06編程軟件、S7-200Modbus指令庫(kù)文件。
2.硬件：PC機(jī)、西門子S7-200PLC（CUP224XP CN REL02.01）、PPI編程電纜、USB-TO-Serial電纜、RS232轉(zhuǎn)RS485模塊。
3.焊接RS485通訊電纜一根（Date+ DB9 3引腳、Date- DB9 8引腳）、RS485通訊電纜連接200PLC的Port0端口。
三、使用Modbus 指令庫(kù)需要注意事項(xiàng)
1.使用Modbus指令庫(kù)，對(duì)STEP7 Micro/win軟件版本的要求。軟件版本必須是V3.2或者以上版本。
2.S7-200 CPU必須是固化程序修訂版2.00或最好支持Modbus主設(shè)備協(xié)議庫(kù)。
3.目前市場(chǎng)已經(jīng)推出針對(duì)端口0和端口1的Modbus RTU主站指令庫(kù)，以及針對(duì)端口0的Modbus RTU從站指令庫(kù)，故在使用時(shí)一定要區(qū)分開。
4.一旦CPU的端口被用于Modbus RTU主站或從站協(xié)議通訊時(shí)，該端口就無(wú)法用于其他用途，包括與STEP7 Micro/win通訊。當(dāng)需要與STEP7 Micro/win通訊時(shí)把CPU打到STOP位即可通訊。
5.利用指令庫(kù)編程前首先應(yīng)為其分配存儲(chǔ)區(qū)，否則Step7-MicroWin在編譯時(shí)會(huì)報(bào)錯(cuò)。分配存儲(chǔ)區(qū)時(shí)在對(duì)話框輸入庫(kù)存儲(chǔ)區(qū)的起始地址，注意避免該地址與程序中其他地址重復(fù)使用，也可以點(diǎn)擊“建議地址”按鈕，系統(tǒng)將自動(dòng)計(jì)算存儲(chǔ)區(qū)分配地址。
四、S7-200 PLC控制器組態(tài)
我們是用ModScan32做主站來讀取從站（S7-200）的數(shù)據(jù)。所以在S7-200 PLC里面只用Modbus從站協(xié)議指令, Modbus從站協(xié)議指令包括MBUS_INT和MBUS_SLVE兩條協(xié)議指令。如圖1
圖 1
1.MBUS_INT指令，用于啟用和初始化或停止Modbus從站通信。在使用MBUS_SLVE指令之前，必須執(zhí)行MBUS_INT指令。在指令完成后立即設(shè)定“完成”位，才能執(zhí)行下一條指令。MBUS_INT指令引腳含義如下：
1.1EN：西門子指令使能位。因?yàn)槭浅跏蓟糜|點(diǎn)SM0.1即可。
1.2Mode：“模式”參數(shù)。用于啟動(dòng)和停止Modbus通信，允許使用以下兩個(gè)數(shù)值：1-啟動(dòng)，2-停止。
1.3Address：“地址”參數(shù)。輸入Modbus從站地址，取值范圍為1～247.
1.4Baud：“波特率”參數(shù)。Baud：“波特率”參數(shù)可選1200、2400、9600、19200等。
1.5Parity：“奇偶校驗(yàn)”參數(shù)。0-無(wú)校驗(yàn)；1-奇校驗(yàn)；2-偶校驗(yàn)。
1.6Delay：“延時(shí)” 參數(shù)。附加字符間延時(shí)，默認(rèn)值為0。
1.7MaxIQ：“最大I/Q位”參數(shù)。設(shè)置參與通信的最大I/O點(diǎn)數(shù)，S7-200的I/O映像區(qū)為128/128，默認(rèn)值為128。
1.8MaxAI：“最大AI字”參數(shù)。設(shè)置參與通信的最大AI通道數(shù)，可為16或32。
1.9MaxHold：設(shè)定供Modbus地址4xxxx使用的V存儲(chǔ)器中的字保持寄存器數(shù)目。
1.10HoldStart：保持寄存器區(qū)起始地址，以&VBx指定。
1.11Done：初始化完成標(biāo)志，成功初始化后置1。
1.12Error：初始化錯(cuò)誤代碼。0-無(wú)錯(cuò)誤。
2.MBUS_SLVE指令，用于Modbus主設(shè)備發(fā)出請(qǐng)求服務(wù)，并且必須每次掃描時(shí)執(zhí)行，以便允許該指令檢查和回復(fù)Modbus請(qǐng)求。MBUS_SLVE指令無(wú)輸入?yún)?shù)，在每次的掃描EN開啟時(shí)執(zhí)行。MBUS_SLVE指令引腳含義如下：
2.1EN：西門子指令使能位。因?yàn)槊總€(gè)周期都需要執(zhí)行，故用SM0.0即可。
2.2Done：“完成”參數(shù)。Modbus執(zhí)行通信時(shí)置1，無(wú)Modbus通信活動(dòng)時(shí)為0。
2.3Error：錯(cuò)誤代碼。0-無(wú)錯(cuò)誤。
五、測(cè)試軟件ModScan32設(shè)置
ModbusRTU測(cè)試軟件ModScan32，在通訊中是中主站，監(jiān)視從站和向從站發(fā)送命令。以下是ModbusRTU測(cè)試軟件ModScan32如圖2： 圖 2
ModScan32測(cè)試軟件的畫面中相關(guān)參數(shù)意義如下:
1.通信端口的選擇。如果PC用的 RS485 轉(zhuǎn)換器接的是串口一（COM1），此下拉選項(xiàng)設(shè)置為 COM1 即可。
2.Baud：波特率的選擇。與S7-200 PLC內(nèi)設(shè)置保持一置。
3.Word：數(shù)據(jù)位。默認(rèn)值8。
4.Parit：奇偶校驗(yàn)。與S7-200 PLC內(nèi)設(shè)置保持一置。
5.Stop：停止位。默認(rèn)值1.
6.Device Id：下位機(jī)地址。與S7-200中MBUS_INT模塊的Address引腳一置。
7.Address：寄存器的起始地址。
8.Length：寄存器長(zhǎng)度。
9.MODBUS Point Type：Modbus點(diǎn)類型選擇。依次出現(xiàn)的是繼電器狀態(tài)、輸入狀態(tài)、鎖存器、輸入寄存器。
10.Number of Polls：發(fā)送和接受命令的次數(shù)。
11.Valid Slave Responses：有效命令的次數(shù)。
六、通訊測(cè)試
S7-200 PLC和測(cè)試軟件ModScan32設(shè)置完畢后，系統(tǒng)上電、通訊線連接好就可以進(jìn)行調(diào)試。Modbus RTU地址與S7-200的地址對(duì)應(yīng)關(guān)系 Modbus地址總是以00001、30004之類的形式出現(xiàn)。S7-200內(nèi)部的數(shù)據(jù)存儲(chǔ)區(qū)與MODBUS的0、1、3、4共4類地址的對(duì)應(yīng)關(guān)系所示:
MODBUS地址
S7-200數(shù)據(jù)區(qū)
00001-00128……………………………Q0.0-Q15.7
10001-10128……………………………I0.0-I15.7
30001-30032……………………………AIW0-AIW32
40001-4xxxx……………………………T + 2*(xxxx-1)
其中T為S7-200中的緩沖區(qū)起始地址，即HoldStart。如果已知S7-200中的V存儲(chǔ)區(qū)地址，推算MODBUS地址的公式為：MODBUS地址=40000+(T/2+1)
篇10
一、借用條款
1、借用條件：
甲方使用乙方的adsl寬帶上網(wǎng)業(yè)務(wù)。
2、甲方借用乙方adsl設(shè)備（限壹臺(tái)），設(shè)備具體描述如下：
品牌：
型號(hào)：
序列號(hào)：
3、該adsl設(shè)備所有權(quán)歸乙方所有，在甲方使用乙方adsl寬帶業(yè)務(wù)的前提下，乙方將此臺(tái)adsl設(shè)備免費(fèi)借給甲方使用。
4、借用期內(nèi)，若甲乙雙方中任何一方提出停借請(qǐng)求，都必須以書面形式提前一個(gè)月通知對(duì)方，經(jīng)雙方協(xié)商一致，甲方歸還adsl設(shè)備給乙方后雙方解除本協(xié)議。
二、雙方的責(zé)任和義務(wù)
1、借用期內(nèi)若甲方暫停使用adsl寬帶業(yè)務(wù)，應(yīng)將adsl設(shè)備歸還乙方，本協(xié)議同時(shí)自動(dòng)終止。用戶恢復(fù)使用adsl業(yè)務(wù)后如需要再借用設(shè)備必須重新簽定借用協(xié)議。
2、借用期內(nèi)若甲方取消使用adsl寬帶業(yè)務(wù)，將視為甲方單方面終止協(xié)議，甲方必須將adsl設(shè)備及時(shí)歸還給乙方，本協(xié)議自動(dòng)終止。
3、乙方保證所提供adsl設(shè)備的質(zhì)量。在借用期內(nèi)，甲方必須妥善保管adsl設(shè)備。
4、借用期內(nèi)，如果adsl設(shè)備因質(zhì)量原因發(fā)生故障，甲方可將設(shè)備帶到乙方處更換。
5、借用期內(nèi)，如果adsl設(shè)備因人為損壞發(fā)生故障，經(jīng)原生產(chǎn)廠家確認(rèn)可以維修，甲方需承擔(dān)維修費(fèi)用，乙方將負(fù)責(zé)提供備用設(shè)備保證甲方正常使用，直到設(shè)備修理好后雙方置換；如果原生產(chǎn)廠家確認(rèn)設(shè)備無(wú)法維修，本協(xié)議自動(dòng)終止，甲方需承擔(dān)設(shè)備賠償責(zé)任，具體賠償金額為____________________元。賠償費(fèi)用一次性在電話______________托收。
6、借用期內(nèi)，乙方免費(fèi)提供該設(shè)備的首次安裝、調(diào)試服務(wù)，并代為培訓(xùn)該設(shè)備的安裝調(diào)測(cè)方法，至于其它范圍的服務(wù)，以乙方公開的服務(wù)承諾為準(zhǔn)。
7、如出現(xiàn)以下情況之一，本協(xié)議將自動(dòng)終止：
第一種情況：甲方暫停使用乙方adsl業(yè)務(wù)；
第二種情況：甲方由adsl業(yè)務(wù)轉(zhuǎn)為其它寬帶業(yè)務(wù)；
第三種情況：甲方不再使用乙方adsl業(yè)務(wù)；
8、協(xié)議終止前甲方應(yīng)將adsl設(shè)備（包括設(shè)備、外包裝、說明書、連線、包裝盒內(nèi)附屬配件等）及其它連同adsl設(shè)備一同借用的附屬設(shè)備（語(yǔ)音分離器等）一并完好歸還。若歸還時(shí)發(fā)生包裝不全、設(shè)備缺損等情況，甲方應(yīng)負(fù)責(zé)補(bǔ)全，否則甲方應(yīng)照價(jià)賠償。
三、爭(zhēng)議和仲裁
1、所有與本協(xié)議執(zhí)行有關(guān)的爭(zhēng)議將通過雙方友好協(xié)商解決，如果雙方不能通過友好協(xié)商解決爭(zhēng)議，則將該爭(zhēng)議提交至鎮(zhèn)江市仲裁委員會(huì)仲裁。
2、仲裁裁定的最終結(jié)果對(duì)雙方均有約束力。
3、仲裁費(fèi)用由敗方承擔(dān)。
4、仲裁進(jìn)行過程中，雙方將繼續(xù)執(zhí)行仲裁部分以外的協(xié)議內(nèi)容。
四、其它事項(xiàng)
1、本協(xié)議由于不可抗力導(dǎo)致不能履行的，雙方均不承擔(dān)違約責(zé)任，共同協(xié)商變更或解除協(xié)議。
2、本協(xié)議與國(guó)家法律法規(guī)或上級(jí)部門的政策和規(guī)定相抵觸時(shí)，應(yīng)依據(jù)國(guó)家法律法規(guī)或上級(jí)部門的政策和規(guī)定變更本協(xié)議。
3、本協(xié)議自雙方簽字蓋章之日起生效，該協(xié)議在甲方使用乙方adsl寬帶業(yè)務(wù)期間有效。本協(xié)議一式兩份，雙方各執(zhí)一份，具有同等法律效力。
篇11
Logistic方程是荷蘭生物學(xué)家Verhulst在19世紀(jì)中葉提出的，它不僅能夠大體上描述人口及許多物種數(shù)量的變化規(guī)律，而且在經(jīng)濟(jì)、管理、傳染病學(xué)等領(lǐng)域也有著廣泛的應(yīng)用。因?yàn)橛蛇@一方程建立的模型能夠描述一些事物符合邏輯的客觀規(guī)律，所以稱它為L(zhǎng)ogistic方程。最初的人口模型是英國(guó)著名人口學(xué)家Malthus調(diào)查了英國(guó)一百多年的人口統(tǒng)計(jì)資料，得出了人口增長(zhǎng)率r不變的假設(shè)，并據(jù)此建立了著名的人口增長(zhǎng)模型
（1）
其中N=N（t）表示時(shí)刻t的人口數(shù)量，N0是初始時(shí)刻人口的數(shù)量，很容易解出
（2）
當(dāng)r>0時(shí)，（1）式表示人口數(shù)量按指數(shù)規(guī)律隨時(shí)間無(wú)限增長(zhǎng)。但從長(zhǎng)期來看，任何地區(qū)的人口都不可能無(wú)限增長(zhǎng)。實(shí)際情況是人口增長(zhǎng)到一定數(shù)量以后，增長(zhǎng)速度就會(huì)慢下來。因?yàn)樽匀毁Y源、環(huán)境條件等因素對(duì)人口的增長(zhǎng)都會(huì)起到阻滯作用，而且隨著人口的增加，這種阻滯作用會(huì)越來越大，所以人口增長(zhǎng)率 就不應(yīng)該是個(gè)常量，應(yīng)該隨人口數(shù)量的增加而變小。不妨令 ，其中Nm是自然資源和環(huán)境條件所容納的最大人口數(shù)量，r為固有增長(zhǎng)率。可以看到當(dāng)N=Nm時(shí)，人口就不再增長(zhǎng)，即r（Nm）=0。于是得到人口的阻滯增長(zhǎng)模型（Logistic模型）
（3）
rN體現(xiàn)人口自身的增長(zhǎng)趨勢(shì)，因子 則體現(xiàn)了資源和環(huán)境對(duì)人口增長(zhǎng)的阻滯作用。若以N為橫軸，dN/dt為縱軸，方程（3）的圖形（圖1），可以看到人
圖1 圖2
口增長(zhǎng)速度dN/dt隨N的變化趨勢(shì)先快后慢，當(dāng)N=Nm/2時(shí)增長(zhǎng)速度最快。方程（3）可以用分離變量法求得 （圖2），是平面上一條S形曲線，人口增長(zhǎng)速度先快后慢，當(dāng)t∞時(shí)，NNm，拐點(diǎn)在N=Nm/2處。這個(gè)模型描繪的人口變化趨勢(shì)與實(shí)際情況基本符合，而方程（3）稱為L(zhǎng)ogistic方程，方程右端帶有阻滯增長(zhǎng)因子。
2 Logistic方程在技術(shù)革新推廣中的應(yīng)用
社會(huì)的進(jìn)步離不開技術(shù)的進(jìn)步創(chuàng)新，對(duì)于一項(xiàng)新技術(shù)在該領(lǐng)域中推廣一直是經(jīng)濟(jì)學(xué)家和社會(huì)學(xué)家關(guān)注的問題。假設(shè)在某一社會(huì)中某領(lǐng)域共有Nm個(gè)企業(yè)，初始時(shí)刻有N0家企業(yè)采用了一項(xiàng)新技術(shù)，N（t）表示t時(shí)刻采用新技術(shù)的企業(yè)數(shù)量， 那么這項(xiàng)技術(shù)如何推廣到該領(lǐng)域中的其它企業(yè)，其它企業(yè)將以怎樣的速度接受該技術(shù)呢？在推廣過程中我們可以認(rèn)為，對(duì)于一個(gè)尚未采用新技術(shù)的企業(yè)家來說，只有當(dāng)采用新技術(shù)的企業(yè)家對(duì)他談?wù)摿嗽摷夹g(shù)后，他才有可能會(huì)采納。那么在t到t+t這段時(shí)間內(nèi)，新增的企業(yè)數(shù)量N應(yīng)該與之前已采納新技術(shù)的企業(yè)數(shù)量N（t）和還不知道這項(xiàng)技術(shù)的企業(yè)數(shù)量Nm-N（t）成正比，即
其中c為比例系數(shù)，它與人們接受新事物的能力，新技術(shù)轉(zhuǎn)化為生產(chǎn)力等方面有關(guān)
當(dāng)t0時(shí)，得
（4）
（5）
方程（4）為技術(shù)革新推廣的Logistic模型，從方程（4）中還可以看到，企業(yè)家采用這一新技術(shù)的速度是先快后慢，當(dāng)數(shù)量未達(dá)到Nm/2時(shí)，接納的速度越來越快，到達(dá)Nm/2后速度開始減慢，直到趨向于零，最終所有的企業(yè)都進(jìn)行了技術(shù)革新，淘汰舊技術(shù)，采用新技術(shù)。
3 Logistic方程在傳染病學(xué)中的簡(jiǎn)單應(yīng)用
隨著科技的進(jìn)步、衛(wèi)生設(shè)施的改進(jìn)、醫(yī)療水平的提高以及人們對(duì)自身健康的關(guān)注，曾經(jīng)一些全球肆虐的傳染病像天花、霍亂已得到控制，但一些新的、變異的傳染病悄悄地向人類襲來。像上世紀(jì)的艾滋病、2003年SARS、今年的H7N9禽流感病毒，給我們的生命和財(cái)產(chǎn)都帶來了極大的危害。因此建立傳染病模型，分析感染人數(shù)的變化規(guī)律是一個(gè)有必要的工作。在這里我們建立關(guān)于傳染病傳播的簡(jiǎn)單模型。
假設(shè)在疾病傳播期內(nèi)所考察地區(qū)的總?cè)藬?shù)N不變，不考慮出生、死亡、遷移。人群分為易感者和已感染者，以下稱為健康人和病人。t時(shí)刻這兩類人在總?cè)藬?shù)中所占比例分別記作s（t）和i（t），每個(gè)病人每天有效接觸人數(shù)為常數(shù)λ，λ稱為日接觸率。那么從t到t+t時(shí)間段內(nèi)新增病人人數(shù)為N[i（t+t）-i（t）]=λNs（t）i（t）t s（t）+i（t）=1
整理得到
當(dāng)t0時(shí)，得 （6）
它的解為 （7）
其中i0為初始時(shí)刻病人所占比例。
由方程（6）及其解（7）同樣可以看到i=1/2時(shí)，病人增加得最快，可以認(rèn)為是醫(yī)院門診量最大的一天，預(yù)示著傳染病的到來，此時(shí) ，當(dāng)有效接觸數(shù)λ越小，這一天來臨得就越晚，所以為了推遲這一天的到來，可以通過改善衛(wèi)生環(huán)境、提高醫(yī)療水平、對(duì)患者作必要的隔絕來降低λ的值。另外一方面，從（7）可以看到當(dāng)t∞時(shí)，i1即所有人都會(huì)感染，顯然不符合實(shí)際。這是因?yàn)槲覀儧]考慮病人會(huì)被治愈，考慮到這一因素，只需要在方程（6）的右端再減去一個(gè)因子μi（μ表示日治愈率）即可，在這里我們就不討論。
由于Logistic方程能夠反映出一些事物本身符合邏輯的規(guī)律，它在社會(huì)、經(jīng)濟(jì)、科學(xué)研究中都有著重要的作用，非常值得我們?nèi)ド钊胙芯俊?/p>
參考文獻(xiàn)：
[1] 龔德恩，范培華.微積分[M].北京：高等教育出版社，2008.
[2] 姜啟源，謝金星，葉俊.數(shù)學(xué)模型（第3版）[M].北京：高等教育出版社，2004.
篇12
作為L(zhǎng)otus Notes和Domino協(xié)作軟件的重大拓展計(jì)劃,IBM Lotus將向Nokia Symbian設(shè)備、BlackBerry、Google Android操作系統(tǒng)和iPhone提供全新支持,以滿足日益增加的移動(dòng)設(shè)備對(duì)企業(yè)應(yīng)用和業(yè)務(wù)流程的需求。
據(jù)IDC預(yù)計(jì),到2011年,市場(chǎng)將有1萬(wàn)億與互聯(lián)網(wǎng)相連接的設(shè)備。為此,Lotus致力于向所有移動(dòng)設(shè)備提供支持,保證用戶無(wú)論身處何處都能夠提供服務(wù)。如今,Lotus已率先為移動(dòng)設(shè)備提供了最廣泛的郵件和協(xié)作支持,包括新版Lotus Notes Traveler軟件將對(duì)Google Android手機(jī)操作系統(tǒng)2.0和2.1版本提供協(xié)作支持。
IBM在本次大會(huì)上了“協(xié)作議程”(Collaboration Agenda),它集合了IBM行業(yè)領(lǐng)域的專家和專業(yè)知識(shí)、軟件實(shí)驗(yàn)室的技術(shù)專家以及咨詢服務(wù)專家,旨在通過協(xié)作技術(shù)和行業(yè)專長(zhǎng),為企業(yè)量身定制協(xié)作路線圖和戰(zhàn)略,幫助企業(yè)改善人員互動(dòng)方式,加速業(yè)務(wù)流程,實(shí)現(xiàn)可衡量回報(bào)。
篇13
工業(yè)控制己從單機(jī)控制走向分散控制，并走入網(wǎng)絡(luò)時(shí)代。工業(yè)控制網(wǎng)絡(luò)為數(shù)據(jù)采集、工業(yè)控制提供了方便，節(jié)省了成本，提高了性能。實(shí)際應(yīng)用中，往往需要不同廠家控制系統(tǒng)的數(shù)據(jù)共享，或某集成系統(tǒng)不能滿足控制需要而額外加系統(tǒng)，需要將2種不同系統(tǒng)進(jìn)行互聯(lián)。
1.Modbus協(xié)議簡(jiǎn)介
Modbus協(xié)議是應(yīng)用于控制器上的一種通用語(yǔ)言。通過此協(xié)議，控制器相互之間、控制器和其他設(shè)備之間可以進(jìn)行通信。它己成為一種通用工業(yè)標(biāo)準(zhǔn)。通過Modbus 協(xié)議，不同廠商生產(chǎn)的控制設(shè)備可以連成工業(yè)網(wǎng)絡(luò)。
標(biāo)準(zhǔn)的Modbus 協(xié)議使用RS-232C兼容串行接口，它定義了連接口的針腳、電纜、信號(hào)位、傳輸波特率、奇偶校驗(yàn)等。控制器能直接或經(jīng)山Modem組網(wǎng)。Modbus協(xié)議將通訊參與者規(guī)定為“主"(Master)和“從”(Slave)。主設(shè)備可單獨(dú)和從設(shè)備通信，也能以廣播方式和所有從設(shè)備通信，而從設(shè)備之間不能通信。
Modbus協(xié)議建立了主設(shè)備查詢的格式:設(shè)備(或廣播)地址、功能代碼、所有要發(fā)送的數(shù)據(jù)、錯(cuò)誤檢測(cè)域。設(shè)備(或廣播)地址提供從機(jī)地址，從機(jī)根據(jù)地址判別是否接收請(qǐng)求，以做出相應(yīng)響應(yīng)，用戶必須設(shè)置每臺(tái)從機(jī)的地址。功能代碼告訴從機(jī)該完成什么樣的動(dòng)作，例如功能代碼3表示讀取從機(jī)保持寄存器并返回其中的內(nèi)容，數(shù)據(jù)區(qū)的內(nèi)容就必須包括從機(jī)的寄存器地址，需要讀的寄存器的個(gè)數(shù)。錯(cuò)誤校驗(yàn)域用于校驗(yàn)信息是否正確傳輸，采用循環(huán)冗長(zhǎng)檢測(cè)方法，CRC域附加在消急的最后，添加時(shí)先是低字節(jié)然后是高字節(jié)。故CRC的高位字節(jié)是發(fā)送消息的最后一個(gè)字節(jié)。
2.通信系統(tǒng)硬件組成及連接
Modbus 協(xié)議運(yùn)行在RS-232/RS-485標(biāo)準(zhǔn)的接口系統(tǒng)中，實(shí)際應(yīng)用中，可根據(jù)現(xiàn)場(chǎng)情況決定用哪一種:RS-232只能實(shí)現(xiàn)一對(duì)一的連接，其傳輸速率局限于20 Kbps,并且傳輸距離在沒有Modem的情況下只有15m左右(用戶可以用Modem擴(kuò)展傳輸距離);RS-485最多可驅(qū)動(dòng)32臺(tái)設(shè)備，其傳輸距離在100 Kbps時(shí)可達(dá)1200m。
TPS系統(tǒng)的RS-485接口最多可以連接15個(gè)設(shè)備，連接方法可參考手冊(cè)，終端要有120Ω的終端電阻。
3.通信系統(tǒng)硬件組態(tài)及編程
3.1 TPS系統(tǒng)組態(tài)
首先對(duì)SI IOP進(jìn)行組態(tài)。在HPM(APM)控制功能組態(tài)中有以下一些參數(shù)與通訊有關(guān):
NNUMERIC：Numeries量的最大個(gè)數(shù)，要求為16的倍數(shù)。
NSTRING：Strings量的最大個(gè)數(shù)，要求為16的倍數(shù)。
NTIME：Times量的最大個(gè)數(shù)，要求為32的倍數(shù)。
NARRSLOT：最大可以設(shè)置256個(gè)A rray點(diǎn)，其中最多80個(gè)可用于SI卡。
SCANPER：指明HPMM(APMM)以多長(zhǎng)的周期掃描SI數(shù)據(jù)并把它們打包進(jìn)Array點(diǎn)中，此參數(shù)影響到A rray點(diǎn)的最大設(shè)置量。當(dāng)掃描周期為1s時(shí)，A rray點(diǎn)最多為80個(gè);當(dāng)掃描周期為0.5s時(shí)，Array點(diǎn)最多為40個(gè);當(dāng)掃描周期為0.25s時(shí)，Array點(diǎn)最多為20個(gè)。
組態(tài)畫面的第2頁(yè)組態(tài)Array點(diǎn)的類型、大小和起始地址索引。注意每種點(diǎn)的類型不能超過其規(guī)定的大小。其起始地址可為。0-99999之間的任意數(shù)值，TPS系統(tǒng)通過起始地址定義Modbus功能號(hào)和數(shù)據(jù)傳送地址，其中最高位決定所選用Modbus功能號(hào)，低4位為Modbus功能號(hào)讀/寫數(shù)據(jù)的地址。
3.2 Siemens PLC中的組態(tài)與編程
CP341/CP441-2模塊是西門子S7-300/400系列PLC中支持Modbus串行通訊的模塊，CP341有1個(gè)(CP441-2有2個(gè))串行通訊口(RS-232C或TTY或RS-485/422)。以使用這種通訊模塊實(shí)現(xiàn)S7 300/400與Modbus主從站通訊，該系統(tǒng)使用CP341。要實(shí)現(xiàn)Modbus通訊時(shí)，需要在CP341/CP441-2模塊上插入相應(yīng)協(xié)議的硬件狗，CP模板才能夠支持Modbus(RTU格式)。
首先安裝STEP7 5.x軟件和CP34.x模板所帶的軟件驅(qū)動(dòng)程序。模板驅(qū)動(dòng)程序包括了對(duì)CP341進(jìn)行參數(shù)化的窗口、用于串行通訊的FB程序塊、模板不同應(yīng)用方式的例子程序，CP341模板手冊(cè)的附錄B中說明了CP模板通訊口的針腳定義。當(dāng)系統(tǒng)上電，CP341模板初始化完成后，SF燈點(diǎn)亮;斷電，在CP模塊上插入Modbus從站硬件狗，然后安裝Modbus從站軟件包，安裝完軟件包后，就可在項(xiàng)目中組態(tài)Modbus從站，雙擊CP341模塊，記錄下模板的硬件地址(編程時(shí)用到此參數(shù))，在模塊的屬性窗口中點(diǎn)擊Parameter:按鈕，選擇Modbus從站協(xié)議，將PC和PLC連接起來，PLC上電，點(diǎn)擊Load Drivers圖標(biāo)，彈出裝載驅(qū)動(dòng)窗口:點(diǎn)擊Load Drivers按鈕，完成從站驅(qū)動(dòng)安裝過程，進(jìn)行Modbus驅(qū)動(dòng)裝載的時(shí)候,PLC必須處于STOP狀態(tài)。再雙擊信封圖標(biāo)，打開Modbus從站參數(shù)設(shè)置窗口，具體設(shè)置參數(shù)有波特率、數(shù)據(jù)位、奇偶校驗(yàn)位、停止位、從站地址等。
設(shè)置完參數(shù)后進(jìn)行編程，F(xiàn)B80是CP341的Modbus通訊功能塊，Modbus通訊功能塊用DB80作為其背景數(shù)據(jù)塊。FB 180是CY441-2的Modbus通訊功能塊，其背景功能塊為DB180，這2個(gè)功能塊必須在用戶程序的循環(huán)程序中運(yùn)行(通常為081)。在081中調(diào)用FB80/ FB180，設(shè)置其輸入輸出參數(shù)，F(xiàn)B80和FB 180中參數(shù)具體可參考手冊(cè)。
PLC每一次冷啟動(dòng)后必須進(jìn)行1次Modbus功能塊初始化設(shè)置，具體體現(xiàn)為給CP_STA-RT 1個(gè)上升沿觸發(fā)信號(hào)，OB100為PLC冷啟動(dòng)后執(zhí)行的第1個(gè)功能塊，此處OB100是為通訊進(jìn)行一些初始化設(shè)置。Modbus通訊功能塊調(diào)用FB 7 "PRCV_RK"(Receive data)和FB 8“P_SN D_RK"(Send data)(CP341)，SFB BSEN D( CP 441-2)進(jìn)行CP和功能塊之間的通信，故相應(yīng)的功能塊也應(yīng)組態(tài)在工程中并下裝到CPU中。
4.結(jié)束語(yǔ)
目前DCS在石化企業(yè)中應(yīng)用相當(dāng)廣泛，但在一些場(chǎng)合，比如開關(guān)量較多、安全可靠性要求不是很高、信號(hào)比較集中等場(chǎng)合，DCS并不是最佳選擇，這時(shí)候也可以考慮PLC和DCS相結(jié)合的方法。使用這種方法，不但減小了TPS系統(tǒng)的控制負(fù)荷，提高了控制精度，而且費(fèi)用較低，起到了良好的經(jīng)濟(jì)效益。 [科]
【參考文獻(xiàn)】