前言：想要寫出一篇令人眼前一亮的文章嗎？我們特意為您整理了5篇ssl協(xié)議范文，相信會為您的寫作帶來幫助，發(fā)現(xiàn)更多的寫作思路和靈感。

ssl協(xié)議范文第1篇

[關鍵詞] 網(wǎng)絡安全 VPN ssl 體系結(jié)構(gòu) 工作模式

VPN（Virtual Personal Network，虛擬專用網(wǎng)）是通過一個私有的通道將遠程用戶、公司分支機構(gòu)、公司業(yè)務伙伴等與公司的企業(yè)網(wǎng)連接起來，構(gòu)成一個擴展的公司企業(yè)網(wǎng),通過在公共網(wǎng)絡中建立專用網(wǎng)絡，數(shù)據(jù)通過安全的“加密通道”在公共網(wǎng)絡中傳播。SSL VPN是一種新的VPN的實現(xiàn)方法，是可靠安全地構(gòu)建VPN的一種模式。

一、SSL協(xié)議

1.SSL概述

SSL（Secure Socket Layer,安全套接層）協(xié)議是 Netscape 公司于1994年提出的一個網(wǎng)絡安全通信協(xié)議，是一種在兩臺機器之間提供安全通道的協(xié)議。它具有保護傳輸數(shù)據(jù)，以及識別通信機器的功能。SSL最初是通過加密HTTP連接為Web瀏覽器提供安全而引入的。

SSL在TCP上提供一種通用的通道安全機制，任何可以在TCP上承載的協(xié)議都能夠使用SSL加以保護。在TCP或IP四層協(xié)議族中，SSL協(xié)議位于傳輸層與應用層之間，基于可靠傳輸協(xié)議TCP，服務于各種應用層協(xié)議，如HTTP、POP、TELNET等，它們在SSL協(xié)議上運行分別被稱作HTTPS、POPS、TELNETS協(xié)議等，分別對應的端口號為443、995、992等。

圖1 SSL協(xié)議結(jié)構(gòu)圖

2.SSL體系結(jié)構(gòu)

SSL協(xié)議在結(jié)構(gòu)上分為兩個層次：底層為記錄層協(xié)議（Record Protocol），負責封裝高層協(xié)議（包括握手協(xié)議）的數(shù)據(jù)，保證SSL連接的數(shù)據(jù)保密性和完整性；高層為握手層，由四個并行的協(xié)議構(gòu)成：握手協(xié)議（Handshake Protocol）、修改密碼參數(shù)協(xié)議（Change Cipher Spec Protocol）、報警協(xié)議（Alert Protocol）、應用數(shù)據(jù)協(xié)議（Application data Protocol），高層協(xié)議需要記錄層協(xié)議支持，其中握手協(xié)議與其他的高層協(xié)議不同，主要負責在交換應用層數(shù)據(jù)之前進行協(xié)商加密算法與密鑰，其他高層協(xié)議屬于應用開發(fā)的范疇，而要得到握手協(xié)議的支持，而握手協(xié)議則是SSL底層實現(xiàn)必須具有的功能，因為記錄層協(xié)議的完成也由它來保證。

二、基于SSL協(xié)議的VPN技術(shù)研究

1.SSLVPN概念

SSL VPN是指一種基于數(shù)據(jù)包封裝技術(shù)的，利用SSL或TLS協(xié)議結(jié)合強加密算法和身份認證技術(shù)的，可靠安全地構(gòu)建VPN的一種方法。它作為一種新的VPN的實現(xiàn)方法，SSL VPN可以用來構(gòu)建外聯(lián)網(wǎng)、內(nèi)聯(lián)網(wǎng)和遠程接入訪問。它通過數(shù)據(jù)包封裝的隧道技術(shù)來實現(xiàn)虛擬專用網(wǎng)的私有性，通過PKI技術(shù)和密碼學技術(shù)來鑒別通信雙方的身份和確保傳輸數(shù)據(jù)的安全。

2.SSL VPN的工作模式

(1)基于Web模式的SSL VPN系統(tǒng)

客戶端使用瀏覽器通過SSLVPN 服務器來訪問企業(yè)局域網(wǎng)的內(nèi)部資源。SSLVPN 服務器相當于一個數(shù)據(jù)中轉(zhuǎn)站，Web瀏覽器對WWW服務器的訪問經(jīng)過SSL VPN服務器的處理（解密、身份鑒別、訪問控制）后轉(zhuǎn)發(fā)給WWW服務器，從WWW服務器發(fā)往Web瀏覽器的數(shù)據(jù)經(jīng)過SSL VPN服務器處理（過濾、加密）后送到Web瀏覽器。

圖2 基于Web模式的SSL VPN系統(tǒng)

(2)基于客戶模式的SSL VPN

用戶在客戶端安裝一個SSL VPN客戶端程序，當客戶端訪問企業(yè)內(nèi)部的應用服務器時，需要經(jīng)過SSL VPN客戶端程序和SSL VPN服務器之間的保密傳輸后才能到達。從而在SSLVPN客戶端和 SSLVPN服務器之間，由SSL協(xié)議構(gòu)建一條安全通道，保護客戶端與SSLVPN服務器之間的數(shù)據(jù)傳輸。此時，SSLVPN服務器充當服務器的角色，SSL VPN客戶端充當客戶端的角色。

圖3 基于客戶端模式的SSL VPN系統(tǒng)

(3)局域網(wǎng)到局域網(wǎng)模式的SSL VPN系統(tǒng)

在網(wǎng)絡邊緣都安裝和配置了SSLVPN服務器。當一個局域網(wǎng)內(nèi)的終端要訪問遠程網(wǎng)絡內(nèi)的應用服務器時，需要經(jīng)過兩個SSL VPN服務器之間的保密傳輸后才能到達。從而在兩個SSLVPN服務器之間，由SSL協(xié)議構(gòu)建一條安全通道，保護局域網(wǎng)之間的數(shù)據(jù)傳輸。此時，SSL VPN服務器充當安全網(wǎng)關的角色。

圖4 局域網(wǎng)到局域網(wǎng)模式的SSL VPN系統(tǒng)

參考文獻:

[1]徐家臻陳莘萌:基于IPSec與基于SSL的VPN的比較與分析[J].計算機工程與設計,2004,(04)

ssl協(xié)議范文第2篇

關鍵詞：SSL；電子商務；數(shù)據(jù)安全

1  引言

隨著計算機技術(shù)和Internet的飛速發(fā)展，商業(yè)活動實現(xiàn)了電子化，從而發(fā)展成為電子商務。電子商務借助互聯(lián)網(wǎng)、企業(yè)內(nèi)部網(wǎng)和增值網(wǎng)等計算機與網(wǎng)絡和現(xiàn)代通信技術(shù)，按照一定的標準，利用電子化工具，將傳統(tǒng)的商業(yè)活動的各個環(huán)節(jié)電子化、網(wǎng)絡化，從而以數(shù)字化方式來進行交易活動和相關服務活動。

電子商務包括電子貨幣交換、供應鏈管理、電子交易市場、網(wǎng)絡營銷、在線事務處理、電子數(shù)據(jù)交換（EDI）、存貨管理和自動數(shù)據(jù)收集系統(tǒng)。電子商務完全不同于傳統(tǒng)的商務活動，它是一種以網(wǎng)絡為載體的新的商務運作方式。

（1）SSL不能提供交易的不可否認性。SSL協(xié)議是基于Web應用的安全協(xié)議，它只能提供安全認證，保證SSL鏈路上的數(shù)據(jù)完整性和保密性。卻不能對電子商務的交易應用層的信息進行數(shù)字簽名，因此，SSL不能提供交易的不可否認性，這可以說是SSL在電子商務中最大的缺陷。

（2）SSL只能提供客戶機到服務器之間的兩方認證，無法適應電子商務中的多方交易業(yè)務。

（3）SSL易遭受Change Cipher Spec消息丟棄攻擊。由于SSL握手協(xié)議中存在一個漏洞：在finished消息中沒有對變換加密的說明消息進行認證處理，在接收到該消息前，所有的密碼族都不做任何加密處理和MAC保護，只有在接收到Change Cipher Spec消息之后，記錄層才開始對通信數(shù)據(jù)進行加密和完整性保護。這種處理機制使得SSL易遭受Change Cipher Spec消息丟棄攻擊。

（4）SSL無法避免通信業(yè)務流分析攻擊。由于SSL位于TCP/IP的協(xié)議層之上，因此，無法對TCP/IP協(xié)議頭部進行保護，導致潛在的隱患。攻擊者通過獲取IP地址、URL請求的長度以及返回的Web頁面的長度等信息，可以分析出用戶訪問的目標，再加上SSL協(xié)議只支持對 塊密碼的隨機填充，沒有提供對流式密碼算法的支持，使得SSL無法阻止這類攻擊。

4  總結(jié)

電子商務正飛速地發(fā)展。用于保障電子商務活動的安全協(xié)議主要有S-HTTP、STT、IKP、SET和SSL。其中SSL協(xié)議是目前電子商務采用的主要的網(wǎng)上交易協(xié)議。SSL協(xié)議采用了加密、認證等安全措施，結(jié)合了Hash算法，較好地保證了數(shù)據(jù)在傳輸過程中的保密性、可靠性和完整性，在一定程度上放置了欺騙、篡改、重放等攻擊。本文在介紹SSL協(xié)議棧及其工作原理和機制的基礎上，對基于SSL的電子商務的安全性進行了分析。

參考文獻：

[1]  邢雙慧.淺談電子商務與SSL協(xié)議[J].硅谷,2010(01):37

ssl協(xié)議范文第3篇

關鍵詞：TLS1.2；安全協(xié)議；計算模型

中圖分類號：TP393

文獻標識碼：A 文章編號：1672-7800（2015）005-0154-04

作者簡介：牛樂園（1990-），女，河南許昌人，中南民族大學計算機科學學院碩士研究生，研究方向為信息安全。

0 引言

人類建立了通信系統(tǒng)后，如何保證通信安全始終是一個重要問題。伴隨著現(xiàn)代通信系統(tǒng)的建立，人們利用數(shù)學理論找到了一些行之有效的方法來保證數(shù)字通信安全。簡單而言就是將雙方通信的過程進行保密處理，比如對雙方通信的內(nèi)容進行加密，這樣可有效防止偷聽者輕易截獲通信內(nèi)容。SSL（Secure Sockets Layer） 及其后續(xù)版本 TLS（Transport Layer Security）是目前較為成熟的通信加密協(xié)議，常被用于在客戶端和服務器之間建立加密通信通道。TLS是安全傳輸層協(xié)議，用于在兩個通信應用程序之間提供保密性和數(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é)議是對SSL協(xié)議規(guī)范后整理的協(xié)議版本，建立在可靠的傳輸層上，如TCP（UDP則不行）。應用層可利用TLS協(xié)議傳輸各種數(shù)據(jù)，來保證數(shù)據(jù)的安全性和保密性[2]。

安全傳輸層協(xié)議（TLS）用于在兩個通信應用程序之間提供保密性和數(shù)據(jù)完整性。該協(xié)議由兩層組成：TLS 記錄協(xié)議（TLS Record）和TLS握手協(xié)議（TLS Handshake）。較低層為 TLS記錄協(xié)議，位于某個可靠的傳輸協(xié)議（如TCP）上。

TLS記錄協(xié)議是一種分層協(xié)議。每一層中的信息可能包含長度、描述和內(nèi)容等字段。記錄協(xié)議支持信息傳輸、將數(shù)據(jù)分段到可處理塊、壓縮數(shù)據(jù)、應用 MAC、加密以及傳輸結(jié)果等，并對接收到的數(shù)據(jù)進行解密、校驗、解壓縮、重組，然后將它們傳送到高層客戶機。

TLS記錄層從高層接收任意大小不間斷的連續(xù)數(shù)據(jù)。密鑰計算：記錄協(xié)議通過算法從握手協(xié)議提供的安全參數(shù)中產(chǎn)生密鑰、IV 和 MAC 密鑰。TLS 握手協(xié)議由3個子協(xié)議組構(gòu)成，允許對等雙方在記錄層的安全參數(shù)上達成一致、自我認證、例示協(xié)商安全參數(shù)、互相報告出錯條件。

TLS握手協(xié)議由3種協(xié)議封裝，包括改變密碼規(guī)格協(xié)議、警惕協(xié)議、握手協(xié)議。TLS協(xié)議結(jié)構(gòu)如圖1所示。

2 TLS1.2消息流程

在整個通訊過程中，為實現(xiàn)TLS的安全連接，服務端與客戶端要經(jīng)歷如下5個階段[3]：①Client申請鏈接，包含自己可以實現(xiàn)的算法列表以及其它信息；②Server回應鏈接，回應中確定了這次通信所使用的算法，將證書發(fā)送給對方，證書中包含了自己的身份和公鑰；③Client在收到消息后會生成一個秘密消息ClientKeyExchange――（此秘密消息經(jīng)處理后，將用作加密密鑰（會話密鑰）），用Web服務器的公鑰加密并傳至Server；④Server再用私鑰解密秘密消息ClientKeyExchange，并進行處理，生成會話密鑰（用于之后的數(shù)據(jù)加密），會話密鑰協(xié)商成功；⑤Client和Server得到會話密鑰，并用此會話密鑰進行數(shù)據(jù)加密。

TLS1.2在傳輸層協(xié)議的消息主要包含8條消息，消息結(jié)構(gòu)如圖2所示，分別是ClientHello版本協(xié)商、ServerHello版本協(xié)商、Server Certificate證書消息、HelloDone接收結(jié)束標識、 ClientKeyExchange即Client交換密鑰消息、Client的Finished消息、CertificateVeri驗證證書消息、Server的Finished消息。

2.1 ClientHello和消息

ClientServer

client_version|| client_random|| session_id|| cipher_suites|| compression_methods|| extensions

消息描述：該消息包括客戶端的版本號client_version，用于告知服務器client可以支持的協(xié)議最高版本，來協(xié)商安全協(xié)議版本。client_random是client產(chǎn)生的一個隨機數(shù)，由client的日期和時間加上28字節(jié)的偽隨機數(shù)組成，用于后面的主密鑰計算。session_id由服務連接得到，發(fā)送給server來建立一個新的會話連接。cipher_suites是client提供給server可供選擇的密碼套件，用于協(xié)商密鑰交換，數(shù)據(jù)加密以及散列算法。compression_methods是客戶端支持的壓縮算法。extensions是客戶端的擴展域。

client_version： Protocol version（協(xié)議版本），該字段表明了客戶能夠支持的最高協(xié)議版本3.3。

random：它由客戶的日期和時間加上28字節(jié)的偽隨機數(shù)組成，該客戶隨機數(shù)將用于計算master secret（主秘密）和prevent replay attacks（防止重放攻擊）。

session_id：一個會話ID標識一個可用的或者可恢復的會話狀態(tài)。一個空的會話ID表示客戶想建立一個新的TLS連接或者會話，而一個非空的會話ID表明客戶想恢復一個先前的會話。session_id有3個來源：①之前的會話連接；②當前連接，客戶端僅僅想通過更新random結(jié)構(gòu)得到連接值時使用；③當前激活的連接，為了建立幾個獨立的連接而不再重復發(fā)起連接握手。

2.2 ServerHello消息

ServerClient：

server_version||server_random|| session_id|| cipher_suites|| compression_methods|| extensions

消息描述：該消息包含6個消息項，server_version取客戶端支持的最高版本號和服務端支持的最高版本號中的較低者，本文所用的是TLS1.2。server _random是服務端生成的隨機數(shù)，由服務器的時間戳加上28字節(jié)的偽隨機數(shù)組成，也用于主密鑰的生成。session_id提供了與當前連接相對應的會話的標識信息。從客戶端處接收到會話標識后，服務器將查找其緩存以便找到一個匹配的session_id。

server_version： Protocol version（協(xié)議版本），取客戶端支持的最高版本號和服務端支持的最高版本號中的較低者。TLS版本為3.3。random：它由客戶的日期和時間加上28字節(jié)的偽隨機數(shù)組成，該客戶隨機數(shù)將用于計算master secret（主秘密）和prevent replay attacks（防止重放攻擊）。session_id：該域提供了與當前連接相對應的會話的標識信息。如果從客戶端接收到的會話標識符非空，則服務器將查找其緩存以便找到一個匹配。

2.3 Server Certificate消息

ServerClient：

version||serialNumber||algorithmIdentifier||issuer||utcTime||subject_name||subject_key_info|| signature

消息描述：該項消息為可選項，證書主要包含4部分內(nèi)容，version是證書版本，文章統(tǒng)一定為X509v3。主體名稱指明使用該證書的用戶為server_subject。subject_key_info是證書包含的公鑰信息，該消息項有兩項內(nèi)容：一個是證書的公鑰，發(fā)送給client后用于加密client生成的預主密鑰，并把密文信息發(fā)送給server。server收到該密文信息后可以使用自己的私鑰解密得到預主密鑰；另一個是所用的散列算法。signature：證書驗證簽名信息，用以驗證證書。version：證書版本號，為X.509V3。subject_name：證書主體名稱。

subject_key_info：標識了兩個重要信息：①主體擁有的公鑰的值；②公鑰所應用算法的標識符。證書私鑰對證書的所有域及這些域的Hash值一起加密。

2.4 ServerKeyExchange消息

ServerClient：

KeyExchangeAlgorithm|| ServerDHParams

KeyExchangeAlgorithm：密鑰交換算法，文章定義的密鑰交換算法為RSA。ServerDHParams：Diffi-Hellman參數(shù)，若交換算法為RSA，則此項為空。

2.5 CertificateRequest消息

ServerClient：

certificate_types|| supported_signature_algorithms|| certificate_authorities

消息描述： 可選消息項，該消息是Server服務器向Client請求驗證證書信息。在一般應用中只對Server服務器進行認證，而Server服務器要允許只有某些授權(quán)的Client才能訪問服務器，此時需要用到該消息對Client進行認證。Client認證是通過Server服務器給Client發(fā)送一條 CertificateRequest消息而開始，如果Server發(fā)送這條消息，則Client必須向server發(fā)送自己的證書。客戶端收到該消息后，發(fā)送一條 Certifcate 消息（與服務器傳送證書的消息一樣）和一條 CertificateVerify 消息予以應答。

certificate_type：客戶端提供的證書類型，該處為rsa_sign。supported_signature_algorithms：可以驗證server的散列/簽名算法對。certificate_authorities：可以接受證書消息的特定名稱。

2.6 Client Certificate消息

ClientServer：

version||serialNumber||algorithmIdentifier||issuer||utcTime||subject_name||subject_key_info|| signature

消息描述：可選消息項，該證書主要包含4部分內(nèi)容，version是證書版本，文章統(tǒng)一定為X509v3。主體名稱指明使用該證書的用戶為server_subject。subject_key_info是證書包含的主要公鑰信息，該消息項有兩項內(nèi)容：一個是證書的公鑰，另一個是所用的散列算法。signature是證書驗證簽名信息，用以驗證證書。

version：證書的版本號，為X.509V3。subject_name：證書主體名稱。subject_key_info：標識了兩個重要信息：①主體擁有的公鑰的值；②公鑰所應用的算法的標識符。算法標識符指定公鑰算法和散列算法（如RSA和SHA-1）。signature：用證書私鑰對證書的所有域及這些域的Hash值一起加密。

2.7 ClientKeyExchange消息

ClientServer：

KeyExchangeAlgorithm|| EncryptedPreMasterSecret

消息描述：該消息是密鑰交換消息。之前的消息協(xié)商中規(guī)定密鑰交換算法為RSA算法，所以該消息中KeyExchangeAlgorithm的內(nèi)容為RSA。此時，client隨機生成一個48字節(jié)的預主密鑰，用從server證書得來的公鑰來加密這個預主密鑰，加密算法為RSA算法。client加密預主密鑰并在ClientKeyExchange消息中將密文EncryptedPreMasterSecret發(fā)給server，使server得到預主密鑰。

KeyExchangeAlgorithm：算法選擇為RSA。EncryptedPreMasterSecret：客戶端生成一個48字節(jié)的預主密鑰，用從server證書得來的公鑰來加密該預主密鑰，加密預主密鑰消息并發(fā)送密文。

2.8 CertificateVerif消息

ClientServer

handshake_messages[handshake_messages_length]

消息描述：可選消息項，如果服務器請求驗證客戶端，則該消息完成服務器驗證過程。客戶端發(fā)送一個certificate_verify消息，其中包含一個簽名，對從第一條消息以來的所有握手消息的HMAC值（用master_secret）進行簽名。handshake_messages指所有發(fā)送或接收的握手消息，從clienthello消息開始到CertificateVerif消息之前（不包括CertificateVerif消息）的所有消息集合，包括握手消息的類型和變長字段。這是到目前為止HandShake結(jié)構(gòu)的整合。

3 Blanchet演算模型建立流程

Blanchet演算模型主要包括類型定義、時間定義、方法定義、通道定義、時間聲明、初始化進程描述[4]、客戶端進程描述與服務端進程描述。TLS1.2最主要的功能體現(xiàn)在客戶端與服務端的消息傳遞。

3.1 協(xié)議事件聲明

在Blanchet演算中首先要聲明要證明的事件。TLS1.2協(xié)議的消息流程中最重要的就是認證性和密鑰的保密性[5]。認證性包括客戶端對服務端的認證和服務端對客戶端的認證，保密性是對會話密鑰的秘密性進行認證。表示server事件發(fā)生之前client事件一定發(fā)生，用來驗證服務端用戶。在更嚴格的定義下進行服務端驗證，事件聲明代碼如下。

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 初始化進程

協(xié)議模型初始化進程如下所示，ClientProcess表示客戶端進程[6]，ServerProcess表示服務端端進程，表示多個ClientProcess進程并發(fā)執(zhí)行，集中一次模擬現(xiàn)實協(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 客戶端和服務端進程

客戶端的消息流程包括版本協(xié)商、算法協(xié)商、密鑰協(xié)商、密鑰交換和請求驗證。版本協(xié)商是協(xié)商客戶端、服務端可以通用的版本[7]，一般是客戶端和服務端都支持的最高版本，密鑰協(xié)商完成后Client向Server發(fā)送verifydata認證請求消息，內(nèi)容包括username、servicename、methodname，method_specific，請求Server驗證身份，并在此定義對客戶端的驗證事件client（verifydata）。

服務端進程首先接收客戶端進程發(fā)送的版本信息[8]，并與自己的版本信息匹配協(xié)商得到協(xié)商版本client_version。版本信息協(xié)商完成后接收客戶端所支持的算法信息，至此算法協(xié)商完成。進入密鑰協(xié)商階段，首先Server接收Client發(fā)送的密鑰參數(shù)信息c_s_random_s，用來計算hash驗證；Server收到Client的驗證請求后對Client進行驗證并接收Client發(fā)來的驗證消息，用所收到的所有消息計算驗證信息。在此插入事件event server（verifydata_fc）來驗證客戶端。

3.4 驗證結(jié)果

本文在介紹TLS1.2協(xié)議的基礎上對其數(shù)據(jù)流程進行分析[9]，使用Blanchet建立模型并分析其安全性和認證性。經(jīng)過一系列的流程跟進并使用自動化證明工具Cryptoverif對TLS1.2進行模型建立，經(jīng)過一系列的Game轉(zhuǎn)換得出分析結(jié)果如圖3所示[10]。結(jié)果證明，TLS1.2協(xié)議的會話密鑰具有安全性，在認證階段能夠?qū)蛻舳送ㄟ^消息簽名進行驗證。

4 結(jié)語

為了研究TLS1.2協(xié)議在應用中的安全性，本文對TLS1.2協(xié)議的消息流程進行了分析。通過對每一步消息流中消息項的研究分析，得出TLS1.2協(xié)議的整體消息結(jié)構(gòu)，最終實現(xiàn)服務端對客戶端的驗證流程分析。基于Blanchet演算對分析的消息流程應用一致性對服務端認證客戶端和客戶端對服務端的驗證建立模型。協(xié)議模型通過協(xié)議轉(zhuǎn)換工具轉(zhuǎn)換為CryptoVerif的輸入代碼TLS1.2.cv，使用CryptoVerif對模型進行分析，并證明了TLS1.2協(xié)議的安全性與認證性。后續(xù)研究中將給出TLS1.2協(xié)議的Java安全代碼，并分析其安全性。

參考文獻：

[1] 陳力瓊，陳克非.認證測試方法對TLS協(xié)議的分析及其應用[J].計算機應用與軟件，2008，25（11）：6-7.

[2] 于代榮，楊揚，馬炳先，等.基于身份的TLS協(xié)議及其BAN邏輯分析[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].消費電子，2013（14）：69-70.

[5] 高志偉，耿金陽.基于優(yōu)先級策略的 TLS 握手協(xié)議研究[J].石家莊鐵道大學學報：自然科學版，2014（3）：69-74.

[6] 唐鄭熠，李祥.Dolev-Yao攻擊者模型的形式化描述[J].計算機工程與科學，2010（8）：36-38.

[7] 邵飛.基于概率進程演算的安全協(xié)議自動化分析技術(shù)研究[D].武漢：中南民族大學，2011.

[8] 朱玉娜.密碼協(xié)議符號分析方法的計算可靠性研究[D].鄭州：信息工程大學，2008.

ssl協(xié)議范文第4篇

關鍵詞：Logistic方程；增長率；日接觸率

1 Logisitic方程的介紹及在人口模型中的應用

Logistic方程是荷蘭生物學家Verhulst在19世紀中葉提出的，它不僅能夠大體上描述人口及許多物種數(shù)量的變化規(guī)律，而且在經(jīng)濟、管理、傳染病學等領域也有著廣泛的應用。因為由這一方程建立的模型能夠描述一些事物符合邏輯的客觀規(guī)律，所以稱它為Logistic方程。最初的人口模型是英國著名人口學家Malthus調(diào)查了英國一百多年的人口統(tǒng)計資料，得出了人口增長率r不變的假設，并據(jù)此建立了著名的人口增長模型

（1）

其中N=N（t）表示時刻t的人口數(shù)量，N0是初始時刻人口的數(shù)量，很容易解出

（2）

當r>0時，（1）式表示人口數(shù)量按指數(shù)規(guī)律隨時間無限增長。但從長期來看，任何地區(qū)的人口都不可能無限增長。實際情況是人口增長到一定數(shù)量以后，增長速度就會慢下來。因為自然資源、環(huán)境條件等因素對人口的增長都會起到阻滯作用，而且隨著人口的增加，這種阻滯作用會越來越大，所以人口增長率 就不應該是個常量，應該隨人口數(shù)量的增加而變小。不妨令 ，其中Nm是自然資源和環(huán)境條件所容納的最大人口數(shù)量，r為固有增長率。可以看到當N=Nm時，人口就不再增長，即r（Nm）=0。于是得到人口的阻滯增長模型（Logistic模型）

（3）

rN體現(xiàn)人口自身的增長趨勢，因子 則體現(xiàn)了資源和環(huán)境對人口增長的阻滯作用。若以N為橫軸，dN/dt為縱軸，方程（3）的圖形（圖1），可以看到人

圖1 圖2

口增長速度dN/dt隨N的變化趨勢先快后慢，當N=Nm/2時增長速度最快。方程（3）可以用分離變量法求得 （圖2），是平面上一條S形曲線，人口增長速度先快后慢，當t∞時，NNm，拐點在N=Nm/2處。這個模型描繪的人口變化趨勢與實際情況基本符合，而方程（3）稱為Logistic方程，方程右端帶有阻滯增長因子。

2 Logistic方程在技術(shù)革新推廣中的應用

社會的進步離不開技術(shù)的進步創(chuàng)新，對于一項新技術(shù)在該領域中推廣一直是經(jīng)濟學家和社會學家關注的問題。假設在某一社會中某領域共有Nm個企業(yè)，初始時刻有N0家企業(yè)采用了一項新技術(shù)，N（t）表示t時刻采用新技術(shù)的企業(yè)數(shù)量， 那么這項技術(shù)如何推廣到該領域中的其它企業(yè)，其它企業(yè)將以怎樣的速度接受該技術(shù)呢？在推廣過程中我們可以認為，對于一個尚未采用新技術(shù)的企業(yè)家來說，只有當采用新技術(shù)的企業(yè)家對他談論了該技術(shù)后，他才有可能會采納。那么在t到t+t這段時間內(nèi)，新增的企業(yè)數(shù)量N應該與之前已采納新技術(shù)的企業(yè)數(shù)量N（t）和還不知道這項技術(shù)的企業(yè)數(shù)量Nm-N（t）成正比，即

其中c為比例系數(shù)，它與人們接受新事物的能力，新技術(shù)轉(zhuǎn)化為生產(chǎn)力等方面有關

當t0時，得

（4）

（5）

方程（4）為技術(shù)革新推廣的Logistic模型，從方程（4）中還可以看到，企業(yè)家采用這一新技術(shù)的速度是先快后慢，當數(shù)量未達到Nm/2時，接納的速度越來越快，到達Nm/2后速度開始減慢，直到趨向于零，最終所有的企業(yè)都進行了技術(shù)革新，淘汰舊技術(shù)，采用新技術(shù)。

3 Logistic方程在傳染病學中的簡單應用

隨著科技的進步、衛(wèi)生設施的改進、醫(yī)療水平的提高以及人們對自身健康的關注，曾經(jīng)一些全球肆虐的傳染病像天花、霍亂已得到控制，但一些新的、變異的傳染病悄悄地向人類襲來。像上世紀的艾滋病、2003年SARS、今年的H7N9禽流感病毒，給我們的生命和財產(chǎn)都帶來了極大的危害。因此建立傳染病模型，分析感染人數(shù)的變化規(guī)律是一個有必要的工作。在這里我們建立關于傳染病傳播的簡單模型。

假設在疾病傳播期內(nèi)所考察地區(qū)的總?cè)藬?shù)N不變，不考慮出生、死亡、遷移。人群分為易感者和已感染者，以下稱為健康人和病人。t時刻這兩類人在總?cè)藬?shù)中所占比例分別記作s（t）和i（t），每個病人每天有效接觸人數(shù)為常數(shù)λ，λ稱為日接觸率。那么從t到t+t時間段內(nèi)新增病人人數(shù)為N[i（t+t）-i（t）]=λNs（t）i（t）t s（t）+i（t）=1

整理得到

當t0時，得 （6）

它的解為 （7）

其中i0為初始時刻病人所占比例。

由方程（6）及其解（7）同樣可以看到i=1/2時，病人增加得最快，可以認為是醫(yī)院門診量最大的一天，預示著傳染病的到來，此時 ，當有效接觸數(shù)λ越小，這一天來臨得就越晚，所以為了推遲這一天的到來，可以通過改善衛(wèi)生環(huán)境、提高醫(yī)療水平、對患者作必要的隔絕來降低λ的值。另外一方面，從（7）可以看到當t∞時，i1即所有人都會感染，顯然不符合實際。這是因為我們沒考慮病人會被治愈，考慮到這一因素，只需要在方程（6）的右端再減去一個因子μi（μ表示日治愈率）即可，在這里我們就不討論。

由于Logistic方程能夠反映出一些事物本身符合邏輯的規(guī)律，它在社會、經(jīng)濟、科學研究中都有著重要的作用，非常值得我們?nèi)ド钊胙芯俊?/p>

參考文獻：

[1] 龔德恩，范培華.微積分[M].北京：高等教育出版社，2008.

[2] 姜啟源，謝金星，葉俊.數(shù)學模型（第3版）[M].北京：高等教育出版社，2004.

[3]周宇虹.Logistic方程及其應用[J].工程數(shù)學，1996（12）：18-21.

ssl協(xié)議范文第5篇

關鍵詞：PLC DCS PROFIBUS-DP 通訊

中圖分類號：TH89 文獻標識碼：A 文章編號：1672-3791（2016）09（a）-0016-02

工業(yè)控制已從單機控制走向集中控制、分散控制，并走向網(wǎng)絡時代。工業(yè)控制網(wǎng)絡為數(shù)據(jù)采集、工業(yè)控制提供了方便，節(jié)省了成本，提高了性能。在實際化工廠工業(yè)控制網(wǎng)絡中，由于控制方式及建設進度等問題，可能會存在多種控制系統(tǒng)。某化工廠原有一套西門子S7-300系列PLC系統(tǒng)用于一套附屬機械設備的邏輯控制，后在實際使用中，需用生產(chǎn)線使用的浙江中控JX-300XP型DCS控制系統(tǒng)對其進行實時監(jiān)控及控制，為減少成本，需建立DCS與PLC之間的通訊系統(tǒng)。西門子S7-300系列PLC系統(tǒng)支持PROFIBUS-DP協(xié)議，故決定選用PROFIBUS-DP協(xié)議通訊的數(shù)字通訊方式，實現(xiàn)兩系統(tǒng)的互聯(lián)。目前改造后的系統(tǒng)運行效果良好。

1 通訊系統(tǒng)結(jié)構(gòu)設計

浙江中控JX-300XP型DCS控制系統(tǒng)有專門用于與PROFIBUS-DP協(xié)議設備通訊用的主站接口卡XP239-DP，它作為SUPCON DCS與PROFIBUS-DP的接口，在PROFIBUS-DP中以主站形式存在。它通過PROFIBUS系統(tǒng)配置工具SYSCON直接與西門子S7-300系列PLC從站接口模塊IM153-1互聯(lián)進行通訊。此種方案可使SUPCON DCS系統(tǒng)直接對西門子S7-300系列PLC的從站接口及IO模塊進行控制，而不必通過西門子PLC的CPU模塊進行通訊轉(zhuǎn)接，降低了系統(tǒng)掃描時間，提高了系統(tǒng)穩(wěn)定性。工程師只需對SUPCON DCS系統(tǒng)進行編程即可，無需再進行西門子的STEP編程，大大降低了編程工作量。

2 通訊系統(tǒng)網(wǎng)絡組成

2.1 PROFIBUS協(xié)議簡介

PROFIBUS是過程現(xiàn)場總線（Process Field Bus）的縮寫，其傳送速度可在9.6kbaud～12Mbaud范圍內(nèi)選擇且當總線系統(tǒng)啟動時，所有連接到總線上的裝置應該被設成相同的速度，廣泛適用于制造業(yè)自動化、流程工業(yè)自動化和樓宇、交通電力等其他領域自動化。PROFIBUS是一種用于工廠自動化車間級監(jiān)控和現(xiàn)場設備層數(shù)據(jù)通信與控制的現(xiàn)場總線技術(shù)，可實現(xiàn)現(xiàn)場設備層到車間級監(jiān)控的分散式數(shù)字控制和現(xiàn)場通信網(wǎng)絡，從而為實現(xiàn)工廠綜合自動化和現(xiàn)場設備智能化提供了可行的解決方案。它以獨特的技術(shù)特點、嚴格的認證規(guī)范、開放的標準、眾多廠商的支持和不斷發(fā)展的應用行規(guī)，已成為最重要的和應用最廣泛的現(xiàn)場總線標準，在多種自動化領域中占據(jù)主導地位，全世界的設備節(jié)點數(shù)已經(jīng)超過2 000萬。

PROFIBUS現(xiàn)場總線通訊協(xié)議包括3個主要部分：（1）PROFIBUS DP：主站和從站之間采用輪循的通訊方式，主要應用于自動化系統(tǒng)中單元級和現(xiàn)場級通信；（2）PROFIBUS PA：電源和通信數(shù)據(jù)通過總線并行傳輸，主要用于面向過程自動化系統(tǒng)中單元級和現(xiàn)場級通訊；（3）PROFIBUS FMS：定義了主站和主站之間的通訊模型，主要用于自動化系統(tǒng)中系統(tǒng)級和車間級的過程數(shù)據(jù)交換。其中，PROFIBUS-DP是高速網(wǎng)絡，通訊速率達到12 M。PROFIBUS-DP可以連接遠程I/O、執(zhí)行機構(gòu)、智能馬達控制器、人機界面HMI、閥門定位器、變頻器等智能設備，1條PROFIBUS-DP總線可以最多連接123個從站設備。PROFIBUS-DP的拓撲結(jié)構(gòu)可以是總線型、星型和樹型，通訊介質(zhì)可以是屏蔽雙絞線、光纖，支持紅外傳輸。

2.2 SYSCON軟件簡介

SyCon是通用的PROFIBUS系統(tǒng)配置工具，具有統(tǒng)一的用戶界面，適用于所有PROFIBUS系統(tǒng)。作為一個基本的配置工具，它使用了所謂的設備描述文件或電子數(shù)據(jù)文檔（EDS文件），這些文件中定義了總線設備的相關特性參數(shù)。這些文件標準化了一些現(xiàn)場總線系統(tǒng)，是由設備制造商提供的，SyCon提供該功能的導入。總線結(jié)構(gòu)是由圖形編輯器決定的，包含了各個現(xiàn)場總線設備。雙擊節(jié)點圖形，可以打開相應的配置窗口。在顯示的表格中，可以創(chuàng)建當前節(jié)點配置的所有可能模塊或數(shù)據(jù)。過程映像中的數(shù)據(jù)地址可以通過配置工具進行手動或自動生成。節(jié)點的參數(shù)化是通過各自現(xiàn)場總線系統(tǒng)的選擇或輸入值實現(xiàn)的。最后一步是總線參數(shù)的定義，它局限于傳輸速率的定義，而所有其他參數(shù)都是各自依據(jù)設備描述文件的基本數(shù)據(jù)。

SyCon提供了全面的診斷功能。在診斷模式下，設備的所有狀態(tài)都被循環(huán)地喚醒，并以紅色或綠色顯示，其依賴于數(shù)據(jù)交換在那時是否正在進行。通過雙擊“紅色”的總線節(jié)點，錯誤的原因代碼就會顯示。更多的功能包括錯誤的讀出、錯誤統(tǒng)計的顯示和過程數(shù)據(jù)的輸入和輸出。

3 通訊系統(tǒng)配置編程

3.1 sycon軟件配置

在進行sycon軟件配置前，需去西門子官網(wǎng)下載所需IM153-1從站通訊模塊的GSD文件，并導入至sycon軟件中。

利用軟件的“Insert->Master”和“Insert->Slave”命令添加主站和從站，并設置好主從站地址。之后，需對主從站及總線參數(shù)進行設置，重點在于從站IO模塊的添加，添加IO模塊時需保證訂貨號與實際模塊保持一致。需注意的是西門子的IO模塊一般可接多種信號，如模擬量輸入模塊，既可接4～20 mA電流信號，又可接0～10 V電壓信號，故進行配置時需對每一個IO模塊的“Parameter Data->Module”進行配置，選擇好每一個模塊通道的信號類型和模塊地址。

3.2 DCS軟件組態(tài)

3.2.1 主站接口卡組態(tài)

在SCKey組態(tài)軟件中，添加XP239-DP主站，配置DP組態(tài)，添加Sycon軟件配置完畢的pb文件，并根據(jù)需要對其進行變量類型及位號的組態(tài)。對于模擬量輸入模塊，其數(shù)據(jù)類型均為有符號整數(shù)，下限為-32768，上限為32767。對于模擬量輸出模塊，上下限即為實際儀表量程，編碼低字節(jié)為0，編碼高字節(jié)為27648。所有變量均選擇參與控制，這樣后期再對備用點進行使用時就無需重新下載DP組態(tài)，不會對生產(chǎn)造成影響。組態(tài)完成后，可通過“查看控制位號”來查看變量地址，字節(jié)偏移/4即為變量地址。

3.2.2 受控主控卡組態(tài)

在DP主站接口卡的受控主控卡內(nèi)建立與DP主站接口卡相對應的半浮點型變量，主控卡與DP接口卡的通訊編程類似于DCS站間通訊的編程，區(qū)別在于需將原DP接口卡中的整形變量轉(zhuǎn)換為半浮點型變量。對于模擬量輸入模塊，主控卡通訊編程中GETMSG模塊的STATION地址即為XP239-DP主站接口卡地址，SERIAL地址為通訊變量在XP239-DP接口卡中的地址。對于模擬量輸出模塊，SETSFLOAT模塊的輸入即為變量地址。

3.2.3 下載調(diào)試

將DP組態(tài)和主控卡組態(tài)分別進行下載，即可有SUPCON DCS操作員對PLC系統(tǒng)進行實時監(jiān)控和控制，而不必再對機械設備進行DCS改造，達到了改造目的。

4 結(jié)語

現(xiàn)代化工對自動化控制水平的要求不斷提高，所采用的控制系統(tǒng)和設備也越來越多，由于制造商的不同，他們各自采用自己的通訊協(xié)議，形成了基于PLC、DCS、FCS并存的各種工業(yè)控制網(wǎng)絡。這就需要利用計算機技術(shù)和網(wǎng)絡技術(shù)將各輔助系統(tǒng)的過程數(shù)據(jù)進行統(tǒng)一監(jiān)控控制，減少監(jiān)控點，從而達到化工生產(chǎn)“分散控制，集中管理”的特點。在該通訊系統(tǒng)中，SUPCON DCS的控制卡件直接連接到了西門子S7-300系列PLC的從站通訊和IO模塊，可使DCS操作員直接對生產(chǎn)輔助設備進行監(jiān)控和控制，降低了成本，極大地方便了自動化工業(yè)現(xiàn)場的控制和操作。自該通信系統(tǒng)運行以來，整個系統(tǒng)通訊正常，有效保證了整個化工控制系統(tǒng)的正常運行。

參考文獻