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

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

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

VPN（Virtual Personal Network，虛擬專用網(wǎng)）是通過一個私有的通道將遠(yuǎn)程用戶、公司分支機(jī)構(gòu)、公司業(yè)務(wù)伙伴等與公司的企業(yè)網(wǎng)連接起來，構(gòu)成一個擴(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年提出的一個網(wǎng)絡(luò)安全通信協(xié)議，是一種在兩臺機(jī)器之間提供安全通道的協(xié)議。它具有保護(hù)傳輸數(shù)據(jù)，以及識別通信機(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等，它們在SSL協(xié)議上運(yùn)行分別被稱作HTTPS、POPS、TELNETS協(xié)議等，分別對應(yīng)的端口號為443、995、992等。

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

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

SSL協(xié)議在結(jié)構(gòu)上分為兩個層次：底層為記錄層協(xié)議（Record Protocol），負(fù)責(zé)封裝高層協(xié)議（包括握手協(xié)議）的數(shù)據(jù)，保證SSL連接的數(shù)據(jù)保密性和完整性；高層為握手層，由四個并行的協(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)于一個數(shù)據(jù)中轉(zhuǎn)站，Web瀏覽器對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

用戶在客戶端安裝一個SSL VPN客戶端程序，當(dāng)客戶端訪問企業(yè)內(nèi)部的應(yīng)用服務(wù)器時，需要經(jīng)過SSL VPN客戶端程序和SSL VPN服務(wù)器之間的保密傳輸后才能到達(dá)。從而在SSLVPN客戶端和 SSLVPN服務(wù)器之間，由SSL協(xié)議構(gòu)建一條安全通道，保護(hù)客戶端與SSLVPN服務(wù)器之間的數(shù)據(jù)傳輸。此時，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)一個局域網(wǎng)內(nèi)的終端要訪問遠(yuǎn)程網(wǎng)絡(luò)內(nèi)的應(yīng)用服務(wù)器時，需要經(jīng)過兩個SSL VPN服務(wù)器之間的保密傳輸后才能到達(dá)。從而在兩個SSLVPN服務(wù)器之間，由SSL協(xié)議構(gòu)建一條安全通道，保護(hù)局域網(wǎng)之間的數(shù)據(jù)傳輸。此時，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)

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

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

1  引言

隨著計(jì)算機(jī)技術(shù)和Internet的飛速發(fā)展，商業(yè)活動實(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è)活動的各個環(huán)節(jié)電子化、網(wǎng)絡(luò)化，從而以數(shù)字化方式來進(jìn)行交易活動和相關(guān)服務(wù)活動。

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

（1）SSL不能提供交易的不可否認(rèn)性。SSL協(xié)議是基于Web應(yīng)用的安全協(xié)議，它只能提供安全認(rèn)證，保證SSL鏈路上的數(shù)據(jù)完整性和保密性。卻不能對電子商務(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é)議中存在一個漏洞：在finished消息中沒有對變換加密的說明消息進(jìn)行認(rèn)證處理，在接收到該消息前，所有的密碼族都不做任何加密處理和MAC保護(hù)，只有在接收到Change Cipher Spec消息之后，記錄層才開始對通信數(shù)據(jù)進(jìn)行加密和完整性保護(hù)。這種處理機(jī)制使得SSL易遭受Change Cipher Spec消息丟棄攻擊。

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

4  總結(jié)

電子商務(wù)正飛速地發(fā)展。用于保障電子商務(wù)活動的安全協(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ǔ)上，對基于SSL的電子商務(wù)的安全性進(jìn)行了分析。

參考文獻(xiàn)：

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

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

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

中圖分類號：TP393

文獻(xiàn)標(biāo)識碼：A 文章編號：1672-7800（2015）005-0154-04

作者簡介：牛樂園（1990-），女，河南許昌人，中南民族大學(xué)計(jì)算機(jī)科學(xué)學(xué)院碩士研究生，研究方向?yàn)樾畔踩?/p>

0 引言

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

安全傳輸層協(xié)議（TLS）用于在兩個通信應(yīng)用程序之間提供保密性和數(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ù)、應(yīng)用 MAC、加密以及傳輸結(jié)果等，并對接收到的數(shù)據(jù)進(jìn)行解密、校驗(yàn)、解壓縮、重組，然后將它們傳送到高層客戶機(jī)。

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

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

2 TLS1.2消息流程

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

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

2.1 ClientHello和消息

ClientServer

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

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

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

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

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

2.2 ServerHello消息

ServerClient：

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

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

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

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)容：一個是證書的公鑰，發(fā)送給client后用于加密client生成的預(yù)主密鑰，并把密文信息發(fā)送給server。server收到該密文信息后可以使用自己的私鑰解密得到預(yù)主密鑰；另一個是所用的散列算法。signature：證書驗(yàn)證簽名信息，用以驗(yàn)證證書。version：證書版本號，為X.509V3。subject_name：證書主體名稱。

subject_key_info：標(biāo)識了兩個重要信息：①主體擁有的公鑰的值；②公鑰所應(yīng)用算法的標(biāo)識符。證書私鑰對證書的所有域及這些域的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請求驗(yàn)證證書信息。在一般應(yīng)用中只對Server服務(wù)器進(jìn)行認(rèn)證，而Server服務(wù)器要允許只有某些授權(quán)的Client才能訪問服務(wù)器，此時需要用到該消息對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的散列/簽名算法對。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)容：一個是證書的公鑰，另一個是所用的散列算法。signature是證書驗(yàn)證簽名信息，用以驗(yàn)證證書。

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

2.7 ClientKeyExchange消息

ClientServer：

KeyExchangeAlgorithm|| EncryptedPreMasterSecret

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

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

2.8 CertificateVerif消息

ClientServer

handshake_messages[handshake_messages_length]

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

3 Blanchet演算模型建立流程

Blanchet演算模型主要包括類型定義、時間定義、方法定義、通道定義、時間聲明、初始化進(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)證性包括客戶端對服務(wù)端的認(rèn)證和服務(wù)端對客戶端的認(rèn)證，保密性是對會話密鑰的秘密性進(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)程，表示多個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é)商、密鑰交換和請求驗(yàn)證。版本協(xié)商是協(xié)商客戶端、服務(wù)端可以通用的版本[7]，一般是客戶端和服務(wù)端都支持的最高版本，密鑰協(xié)商完成后Client向Server發(fā)送verifydata認(rèn)證請求消息，內(nèi)容包括username、servicename、methodname，method_specific，請求Server驗(yàn)證身份，并在此定義對客戶端的驗(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)證請求后對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ǔ)上對其數(shù)據(jù)流程進(jìn)行分析[9]，使用Blanchet建立模型并分析其安全性和認(rèn)證性。經(jīng)過一系列的流程跟進(jìn)并使用自動化證明工具Cryptoverif對TLS1.2進(jìn)行模型建立，經(jīng)過一系列的Game轉(zhuǎn)換得出分析結(jié)果如圖3所示[10]。結(jié)果證明，TLS1.2協(xié)議的會話密鑰具有安全性，在認(rèn)證階段能夠?qū)蛻舳送ㄟ^消息簽名進(jìn)行驗(yàn)證。

4 結(jié)語

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

參考文獻(xiàn)：

[1] 陳力瓊，陳克非.認(rèn)證測試方法對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)先級策略的 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é)議自動化分析技術(shù)研究[D].武漢：中南民族大學(xué)，2011.

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

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

關(guān)鍵詞：Logistic方程；增長率；日接觸率

1 Logisitic方程的介紹及在人口模型中的應(yīng)用

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

（1）

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

（2）

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

（3）

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

圖1 圖2

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

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

社會的進(jìn)步離不開技術(shù)的進(jìn)步創(chuàng)新，對于一項(xiàng)新技術(shù)在該領(lǐng)域中推廣一直是經(jīng)濟(jì)學(xué)家和社會學(xué)家關(guān)注的問題。假設(shè)在某一社會中某領(lǐng)域共有Nm個企業(yè)，初始時刻有N0家企業(yè)采用了一項(xiàng)新技術(shù)，N（t）表示t時刻采用新技術(shù)的企業(yè)數(shù)量， 那么這項(xiàng)技術(shù)如何推廣到該領(lǐng)域中的其它企業(yè)，其它企業(yè)將以怎樣的速度接受該技術(shù)呢？在推廣過程中我們可以認(rèn)為，對于一個尚未采用新技術(shù)的企業(yè)家來說，只有當(dāng)采用新技術(shù)的企業(yè)家對他談?wù)摿嗽摷夹g(shù)后，他才有可能會采納。那么在t到t+t這段時間內(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時，得

（4）

（5）

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

3 Logistic方程在傳染病學(xué)中的簡單應(yīng)用

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

假設(shè)在疾病傳播期內(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

整理得到

當(dāng)t0時，得 （6）

它的解為 （7）

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

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

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

參考文獻(xiàn)：

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

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

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

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

關(guān)鍵詞：modbus協(xié)議；溫度采集；水泵房；S7-300PLC

中圖分類號：TN915 文獻(xiàn)標(biāo)識碼：A

0.前言

錢家營礦的涌水量比較大，共設(shè)置了3個水平的泵房，伴隨著全自動化礦井的建設(shè)，需要對-600水泵房和-850水泵房進(jìn)行升級改造，水泵和電機(jī)的溫度參數(shù)保證著水泵的安全運(yùn)行，每個水泵房共設(shè)置10臺排水泵，每臺水泵通過YBD-200溫度巡檢儀進(jìn)行溫度采集，該儀表采用的是modbus協(xié)議通過RS485總線接口傳輸?shù)絇LC，經(jīng)過PLC處理，傳輸?shù)降孛嫔衔粰C(jī)實(shí)時顯示。

1.溫度巡檢儀通信協(xié)議

YBD200型儀表采用的是標(biāo)準(zhǔn)modbus協(xié)議，RTU傳輸模式。Modbus協(xié)議是一種主-從通信協(xié)議。任何時刻只有一個設(shè)備能夠在線路上進(jìn)行發(fā)送。由主站點(diǎn)管理信息交換，且只有它能發(fā)起。它會相繼對從站進(jìn)行輪詢。除非被主站批準(zhǔn)，否則任何從站都不能發(fā)送消息。從站之間不能進(jìn)行直接通信。協(xié)議幀中不包含任何消息報(bào)頭字節(jié)或消息字節(jié)結(jié)束符。

1.它的定義如下（見表1）：

從站地址：消息中的地址包含一個字節(jié)，從站地址范圍是1…255。主設(shè)備通過將要聯(lián)絡(luò)的從設(shè)備的地址放入消息中的地址域來選通從設(shè)備。當(dāng)從設(shè)備發(fā)送回應(yīng)消息時，它把自己的地址放入回應(yīng)的地址域中，以便主設(shè)備知道是哪一個設(shè)備做出回應(yīng)。數(shù)據(jù)：以二進(jìn)制代碼傳輸。CRC16：循環(huán)冗余錯誤校驗(yàn)。采用的是9600bps的波特率。字節(jié)數(shù)據(jù)格式：一位起始位，八位數(shù)據(jù)位，一位偶校驗(yàn)位，一位停止位。從站地址編號：儀表地址必須在1～255之間，且同一總線上，每個儀表的地址不可重復(fù)。當(dāng)字符間隔時間長于或等于3.5個字符時，即作為檢測到幀的結(jié)束。

2.讀取寄存器

主站請求（表2）：

從站響應(yīng)（表3）：

例如溫度巡檢儀的地址為10，利用串口調(diào)試軟件Com Monitor，進(jìn)行發(fā)送數(shù)據(jù)：0A 03 00 00 00 07 05 73得到的數(shù)據(jù)為：0A 03 0E 00 C6 00 BA 01 0B 01 3C 01 8F 01 8F 01 8F DC ED，表示該儀表通信正常。

3.硬件組成和接線

水泵的電控系統(tǒng)主要由一臺集控柜和10臺就地柜等組成，集控柜安裝有315-2DP的CPU模塊和CP343-1的以太網(wǎng)模塊、CP340-RS422/RS485通信模塊以及數(shù)字量、模擬量輸入輸出模塊等，溫度探頭選用的是Pt100鉑電阻類型的，把7點(diǎn)的溫度數(shù)據(jù)接到Y(jié)BD-200型溫度巡檢儀對應(yīng)的端子上，一共采集10臺水泵的溫度數(shù)據(jù)，每塊溫度巡檢儀均通過RS485總線接至集控柜中CP340-RS422/RS485的接口上，把10塊溫度巡檢儀的A端并聯(lián)的一起接到CP340-RS422/RS485的1#端子，B端并聯(lián)的一起接到CP340-RS422/RS485的2#端子即可，并且需要把CP340-RS422/RS485的5#端子進(jìn)行接地處理，抗干擾能力強(qiáng)。

4. PLC程序的編寫

現(xiàn)場使用YBD-200型溫度巡檢儀的地址編號為4-13，為了防止數(shù)據(jù)的讀取錯誤，編寫主站PLC程序時，可通過增計(jì)數(shù)器進(jìn)行從站地址4-13的輪詢，并設(shè)置0.5s時鐘寄存器進(jìn)行控制。為了保證發(fā)送報(bào)文的準(zhǔn)確性，發(fā)送報(bào)文之前先利用事先編好CRC校驗(yàn)子程序檢驗(yàn)一下，CRC校驗(yàn)子程序采用的是CRC16算法。

PLC與溫度巡檢儀主要通過調(diào)用FB2、FB3系統(tǒng)塊實(shí)現(xiàn)主從站的請求和讀取功能。需要注意的是，調(diào)用FB2、FB3時，地址為CP340-RS422/RS485硬件組態(tài)時的地址352；主站請求時從DB3數(shù)據(jù)塊中的DBB0字節(jié)開始調(diào)用，字長為8。主站讀取從站數(shù)據(jù)時，從DB8數(shù)據(jù)塊中的DBB0字節(jié)開始寫入，DB8塊數(shù)據(jù)先進(jìn)行CRC子程序檢驗(yàn)其正確性，然后再編程實(shí)現(xiàn)分組對應(yīng)到DB7數(shù)據(jù)塊中，從DB7.DBD0字節(jié)定義存儲溫度巡檢儀4#地址數(shù)據(jù)，依次是電機(jī)前軸、電機(jī)后軸、泵前軸、泵后軸、定子A相、定子B相、定子C相。依次類推，從DB7.DBD28開始存儲5#地址的7點(diǎn)溫度數(shù)據(jù)，一共存儲10臺水泵的溫度參數(shù)。

通過CP343-1以太網(wǎng)模塊將PLC中的數(shù)據(jù)可以全部接入全礦自動化平臺進(jìn)行數(shù)據(jù)共享，上位機(jī)利用西門子公司的wincc6.2進(jìn)行編寫繪制，通過編程實(shí)現(xiàn)將DB7中的溫度數(shù)據(jù)全部讀取到wincc中，同時也可以增加其他的故障信息。

結(jié)語

本文通過modbus協(xié)議RS485總線技術(shù)實(shí)現(xiàn)了現(xiàn)場溫度的采集，但在現(xiàn)場使用中發(fā)現(xiàn)，溫度巡檢儀的地址是固化的，如若巡檢儀損壞后，互換性較差，先已進(jìn)行溫度巡檢儀的升級，使每臺溫度巡檢儀的地址可在0～255之間任意調(diào)整，并將溫度巡檢儀使用的RS485總線模塊更換為MAX485具有光電隔離功能，大大增加了設(shè)備的安全性和穩(wěn)定性。

參考文獻(xiàn)

[1]史運(yùn)濤，孫德輝，李志軍，等.基于Modbus協(xié)議的通信集成技術(shù)研究[J].化工自動化及儀表，2010，37（4）：67-72.