第一篇：電子商務(wù)安全協(xié)議SSL、SET的分析與研究演講稿

第一張：標(biāo)題 第二張：SSL 概念：安全套接層(Secure Sockets Layer，SSL)是一種傳輸層技術(shù)，可以實(shí)現(xiàn)兼容瀏覽器和服務(wù)器之間的安全通信。SSL協(xié)議是目前網(wǎng)上購物網(wǎng)站中常使用的一種安全協(xié)議。

1.SSL協(xié)議提供的服務(wù)主要有

(1)用戶和服務(wù)器的合法性認(rèn)證；

(2)加密數(shù)據(jù)以隱藏被傳送的數(shù)據(jù)；(3)維護(hù)數(shù)據(jù)的完整性，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é)束的信息。

3.SSL協(xié)議的缺點(diǎn)

（1）客戶的信息先到商家，讓商家閱讀，這樣，客戶資料的安全性就得不到保證。

（2）SSL只能保證資料信息傳遞的安全，而傳遞過程是否有人截取就無法保證了。所以，SSL并沒有實(shí)現(xiàn)電子支付所要求的保密性、完整性，而且多方互相認(rèn)證也是很困難的。

4.電子商務(wù)中的應(yīng)用。電子商務(wù)與網(wǎng)上銀行交易不同，因?yàn)橛猩虘魠⒓?，形成客戶――商家――銀行，兩次點(diǎn)對(duì)點(diǎn)的SSL連接?？蛻?，商家，銀行，都必須具證書，兩次點(diǎn)對(duì)點(diǎn)的雙向認(rèn)證。

第三張SET 概念: SET協(xié)議是由VISA和MasterCard兩大信用卡公司于1997年5月聯(lián)合推出的規(guī)范。SET主要是為了解決用戶、商家和銀行之間通過信用卡支付的交易而設(shè)計(jì)的，以保證支付信息的機(jī)密、支付過程的完整、商戶及持卡人的合法身份、以及可操作性。SET中的核心技術(shù)主要有公開密鑰加密、電子數(shù)字簽名、電子信封、電子安全證書等。

1。SET支付系統(tǒng)的組成

SET支付系統(tǒng)主要由持卡人、商家、發(fā)卡行、收單行、支付網(wǎng)關(guān)、認(rèn)證中心等六個(gè)部分組成。對(duì)應(yīng)地，基于SET協(xié)議的網(wǎng)上購物系統(tǒng)至少包括電子錢包軟件、商家軟件、支付網(wǎng)關(guān)軟件和簽發(fā)證書軟件。

2。SET安全協(xié)議主要提供三方面的服務(wù)

（1）保證客戶交易信息的保密性和完整性：

（2）確保商家和客戶交易行為的不可否認(rèn)性：

（3）確保商家和客戶的合法性：

3。SET協(xié)議的缺點(diǎn)

（1）只能建立兩點(diǎn)之間的安全連線，所以顧客只能把付款信息先發(fā)送到商家，再由商家轉(zhuǎn)發(fā)到銀行，而且只能保證連接通道是安全的而沒有其他保證。

（2）不能保證商家會(huì)私自保留或盜用他的付款信息。

4.SET的工作流程

①消費(fèi)者在互聯(lián)網(wǎng)選所要購買的物品，并在計(jì)算機(jī)上輸入訂貨單

②通過電子商務(wù)服務(wù)器與有關(guān)商家聯(lián)系，商家作出應(yīng)答，告訴消費(fèi)者所填訂貨單的貨物單價(jià)、應(yīng)付款數(shù)、交貨方式等信息是否準(zhǔn)確、是否有變化

③消費(fèi)者選擇付款方式，確認(rèn)訂單，簽發(fā)付款指令，此時(shí)SET開始介入 ④在SET中，消費(fèi)者必須對(duì)訂單和付款指令進(jìn)行數(shù)字簽名，同時(shí)利用雙重簽名技術(shù)保證商家看不到消費(fèi)者的足球新聞賬號(hào)信息

⑤商家接受訂單后，向消費(fèi)者所在銀行請(qǐng)求支付認(rèn)可，信息通過支付網(wǎng)關(guān)到收單銀行，再到電子貨幣發(fā)行公司確認(rèn)，批準(zhǔn)交易后，返回確認(rèn)信息給商家

⑥商家發(fā)送訂單確認(rèn)信息給消費(fèi)者，消費(fèi)者端軟件可記錄交易日志，以備查詢

⑦商家發(fā)送貨物或提供服務(wù)，并通知收單銀行將錢從消費(fèi)者的賬號(hào)轉(zhuǎn)移到商店賬號(hào)，或通知發(fā)卡銀行請(qǐng)求支付。

第四張：SSL與SET協(xié)議的比較

（1）在認(rèn)證要求方面，早期的SSL并沒有提供商家身份認(rèn)證機(jī)制，不能實(shí)現(xiàn)多方認(rèn)證；而SET的安全要求較高，所有參與SET交易的成員都必須申請(qǐng)數(shù)字證書進(jìn)行身份識(shí)別。

（2）在安全性方面，SET協(xié)議規(guī)范了整個(gè)商務(wù)活動(dòng)的流程，從而最大限度地保證了商務(wù)性、服務(wù)性、協(xié)調(diào)性和集成性。而SSL只對(duì)持卡人與商店端的信息交換進(jìn)行加密保護(hù)，可以看作是用于傳輸?shù)哪遣糠值募夹g(shù)規(guī)范。從電子商務(wù)特性來看，它并不具備商務(wù)性、服務(wù)性、協(xié)調(diào)性和集成性。因此SET的安全性比SSL高。

（3）在網(wǎng)絡(luò)層協(xié)議位置方面，SSL是基于傳輸層的通用安全協(xié)議，而SET位于應(yīng)用層，對(duì)網(wǎng)絡(luò)上其他各層也有涉及。

（4）在應(yīng)用領(lǐng)域方面，SSL主要是和Web應(yīng)用一起工作，而SET是為信用卡交易提供安全，但如果電子商務(wù)應(yīng)用是一個(gè)涉及多方交易的過程，則使用SET更安全、更通用些。

總結(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)地位。

第二篇：淺析電子商務(wù)安全協(xié)議SSL與SET

淺析電子商務(wù)安全協(xié)議SSL與SET

一、引言

電子商務(wù)融計(jì)算機(jī)技術(shù)、通信技術(shù)、網(wǎng)絡(luò)技術(shù)于一體，以Internet為基礎(chǔ)平臺(tái)，互動(dòng)性、開放性、廣泛性為其顯著特點(diǎn)。由于其開放性與廣泛性，必然面臨各種安全風(fēng)險(xiǎn)，如信息泄露或被篡改、欺騙、抵賴等。所以，安全問題已成為發(fā)展可信賴電子商務(wù)環(huán)境的瓶頸。目前，眾多的安全技術(shù)都是通過安全協(xié)議來實(shí)施的。因此，簡(jiǎn)潔、有效的安全協(xié)議對(duì)電子商務(wù)安全而言至關(guān)重要?，F(xiàn)今，國際上主要通行的兩種安全協(xié)議：安全套接層協(xié)議SSL和安全電子交易協(xié)議SET，二者均是成熟和實(shí)用的安全協(xié)議，但是由于它們的設(shè)計(jì)目的不同，所以在應(yīng)用上有很大的差別。

二、兩種電子商務(wù)安全協(xié)議介紹

（一）安全套接層協(xié)議SSL

SSL是網(wǎng)景(Netscape)公司提出的基于WEB應(yīng)用的安全協(xié)議，其目的是在Internet基礎(chǔ)上提供的一種保證機(jī)密性的安全協(xié)議。它能使客戶端／服務(wù)器應(yīng)用之間的通信不被攻擊者竊聽，并且始終對(duì)服務(wù)器進(jìn)行認(rèn)證，而且還可選擇對(duì)客戶端進(jìn)行認(rèn)證。

SSL協(xié)議是國際上最早應(yīng)用于電子商務(wù)的一種網(wǎng)絡(luò)安全協(xié)議，主要用于提高應(yīng)用程序之間的數(shù)據(jù)安全。它同時(shí)使用對(duì)稱加密算法和公鑰加密算法，前者在速度上比后者要快很多，但是后者可以實(shí)現(xiàn)更好的安全認(rèn)證。一個(gè)SSL傳輸過程首先需要握手：用公鑰加密算法使服務(wù)器在客戶端得到認(rèn)證，以后就可以使用雙方商議成功的對(duì)稱密鑰來更快速的加密、解密數(shù)據(jù)。

SSL協(xié)議要求建立在可靠的傳輸層協(xié)議(例如：TCP)之上。SSL協(xié)議的優(yōu)勢(shì)在于它是與應(yīng)用層協(xié)議獨(dú)立無關(guān)的。高層的應(yīng)用層協(xié)議(例如：HTTP，F(xiàn)TP)能透明地建立于SSL協(xié)議之上。SSL協(xié)議在應(yīng)用層協(xié)議通信之前就已經(jīng)完成加密算法、通信密鑰的協(xié)商以及服務(wù)器認(rèn)證工作。應(yīng)用層協(xié)議所傳送的數(shù)據(jù)都會(huì)被加密，從而保證通信的機(jī)密性。對(duì)于電子商務(wù)應(yīng)用來說，使用SSL可保證信息的真實(shí)性、完整性和保密性。SSL協(xié)議由SSL記錄協(xié)議和SSL握手協(xié)議兩部分組成。

1、SSL記錄協(xié)議

在SSL協(xié)議中，所有的傳輸數(shù)據(jù)都被封裝在記錄中。所有的SSL通信，包括握手消息、安全空白記錄和應(yīng)用數(shù)據(jù)都使用SSL記錄協(xié)議。記錄協(xié)議允許服務(wù)器和客戶端相互認(rèn)證并協(xié)商加密算法和密鑰，對(duì)所有發(fā)送和接收的數(shù)據(jù)進(jìn)行分段、壓縮、認(rèn)證、加密和完整性服務(wù)。

2、SSL握手協(xié)議

SSL握手協(xié)議包括建立在記錄協(xié)議之上的握手協(xié)議、警報(bào)協(xié)議、更改加密說明協(xié)議和應(yīng)用數(shù)據(jù)協(xié)議等對(duì)會(huì)話和管理提供支持的子協(xié)議，其用于在通信雙方之間建立安全傳輸通道。握手過程一般分為4個(gè)階段：

(1)初始化邏輯連接，客戶端先發(fā)出ClientHello消息，服務(wù)器返回一個(gè)ServerHello消息，這兩個(gè)消息用來協(xié)商雙方的安全能力，包括協(xié)議版本、對(duì)稱加密算法、壓縮算法等。

(2)服務(wù)器發(fā)送數(shù)字證書(包含了服務(wù)器的公鑰等)和會(huì)話密鑰。如果服務(wù)器要求認(rèn)證客戶端，則要發(fā)送CertificateRequest消息。最后服務(wù)器發(fā)送ServerHelloDone消息，表示hello階段結(jié)束，服務(wù)器等待客戶端的響應(yīng)。

(3)如果服務(wù)器要求認(rèn)證客戶端，則客戶端先發(fā)送Certificate消息，然后產(chǎn)生會(huì)話密鑰，并用服務(wù)器的公鑰加密，封裝在ClientKeyExchange消息中，如果客戶端發(fā)送了自己的數(shù)字證書，則再發(fā)送一個(gè)數(shù)字簽名CertificateVerify來對(duì)數(shù)字證書進(jìn)行校驗(yàn)。

(4)客戶端發(fā)送一個(gè)ChangeCipherspec消息，通知服務(wù)器以后發(fā)送的消息將采用先前協(xié)商好的安全參數(shù)加密，最后再發(fā)送一個(gè)加密后的Finished消息。服務(wù)器在收到上述兩個(gè)消息后，也發(fā)送自己的ChangeCipherspec消息和Finished消息。

至此，握手全部完成，雙方就可以開始傳輸應(yīng)用數(shù)據(jù)了。

3、SSL提供的功能及局限性

SSL使用加密的辦法建立一個(gè)安全的傳輸通道,它可提供以下3種基本的安全服務(wù)功能：

(1)信息加密?？蛻舳撕头?wù)器之間的所有的應(yīng)用數(shù)據(jù)使用在SSL握手過程中建立的密鑰和算法進(jìn)行加密。這樣就防止了某些用戶通過使用IP packet sniffer等工具進(jìn)行非法竊聽或者破譯。

(2)信息完整。SSL提供完整信息服務(wù)，以建立客戶端與服務(wù)器之間的安全通道，使所有經(jīng)過SSL協(xié)議處理的業(yè)務(wù)能全部準(zhǔn)確無誤地到達(dá)目的地。

(3)相互認(rèn)證?？蛻舳撕头?wù)器都有各自的識(shí)別號(hào)，這些識(shí)別號(hào)由公開密鑰進(jìn)行編號(hào)。為了認(rèn)證用戶是否合法，SSL協(xié)議要求在握手交換數(shù)據(jù)前進(jìn)行數(shù)字認(rèn)證，來確保用戶的合法性。

SSL協(xié)議的局限性：首先，客戶的信息先到商家，讓商家閱讀，這樣，客戶資料的安全性就得不到保證；其次，SSL只能保證資料信息傳遞的安全，而傳遞過程是否有人截取就無法保證了。所以，SSL并沒有實(shí)現(xiàn)電子支付所要求的保密性、完整性，而且多方互相認(rèn)證也是很困難的。此外，該協(xié)議最大的弱點(diǎn)是不能做數(shù)字簽名，因此不支持不可否認(rèn)性。另外，它不能對(duì)商家進(jìn)行認(rèn)證，不能防止網(wǎng)上欺詐行為。

（二）安全電子交易協(xié)議SET

安全電子交易(Secure Electronic Transaction．簡(jiǎn)稱SET)協(xié)議是由Visa和Master Card公司在1996年底開發(fā)的，主要為在網(wǎng)上在線交易時(shí)保證使用信用卡進(jìn)行支付時(shí)的安全而設(shè)立的一個(gè)開放的協(xié)議，它是面向網(wǎng)上交易，針對(duì)利用信用卡進(jìn)行支付而設(shè)計(jì)的電子支付規(guī)范。SET提供了消費(fèi)者、商家和銀行之間的認(rèn)證，確保交易的保密性、可靠性和不可否認(rèn)性，從而保證在開放網(wǎng)絡(luò)環(huán)境下使用信用卡進(jìn)行在線購物的安全。目前，SET已得到IBM、Microsoft、VeriSign等著名公司的參與和支持，是國際上所公認(rèn)的Internet電子商務(wù)的安全標(biāo)準(zhǔn)。

1、基于SET的交易流程

SET協(xié)議的購物系統(tǒng)由持卡人、商家、支付網(wǎng)關(guān)、收單銀行、發(fā)卡銀行和證書授權(quán)中心(CA)等六大部分組成，它們之間的關(guān)系如圖1所示。

此外，基于SET協(xié)議的購物系統(tǒng)至少包括電子錢包軟件、商家軟件、支付網(wǎng)關(guān)軟件和簽發(fā)數(shù)字證書軟件。目前，SET電子錢包主要是安裝在客戶端的交易軟件，它是持卡人實(shí)現(xiàn)網(wǎng)上交易過程的主要工具。

SET協(xié)議在一般環(huán)境下的工作步驟如下：

(1)持卡人注冊(cè)：持卡人為了使用信用卡，必須向支持SET的發(fā)卡銀行申請(qǐng)開戶，從而獲得一個(gè)可用于Internet支付的信用卡帳號(hào)，同時(shí)向CA申請(qǐng)?jiān)撔庞每ǖ臄?shù)字證書。此后，持卡人可以使用終端進(jìn)行購物。

(2)商家注冊(cè)：商家同樣向CA申請(qǐng)用于電子商務(wù)支付的數(shù)字證書。此后，商家可以在網(wǎng)絡(luò)上開設(shè)商城來銷售貨物。

(3)持卡人利用電子商務(wù)平臺(tái)選定物品，并提交定單；

(4)商家接收定單，生成初始應(yīng)答消息，數(shù)字簽名后與商家數(shù)字證書、支付網(wǎng)關(guān)數(shù)字證書一起發(fā)送給持卡人；

(5)持卡人對(duì)應(yīng)答消息進(jìn)行處理，選擇支付方式，確認(rèn)定單，簽發(fā)付款指令，將定單信息和支付信息進(jìn)行雙簽名，對(duì)雙簽名后的信息和用支付網(wǎng)關(guān)公鑰加密的支付信息簽名后連同自己的數(shù)字證書發(fā)送給商家(商家看不到持卡人的帳號(hào)信息)；

(6)商家認(rèn)證持卡人數(shù)字證書和雙簽名后，生成支付認(rèn)可請(qǐng)求，并連同加密的支付信息轉(zhuǎn)發(fā)給支付網(wǎng)關(guān)；

(7)支付網(wǎng)關(guān)通過金融專網(wǎng)到發(fā)卡銀行認(rèn)證持卡人的帳號(hào)信息，并生成支付認(rèn)可消息，數(shù)字簽名后發(fā)給商家；

(8)商家收到支付認(rèn)可消息后，認(rèn)證支付網(wǎng)關(guān)的數(shù)字簽名，生成購買定單確認(rèn)信息發(fā)送給持卡人。

至此交易過程結(jié)束。商家發(fā)送貨物或提供服務(wù)并請(qǐng)求支付網(wǎng)關(guān)將購物款從發(fā)卡銀行持卡人的帳號(hào)轉(zhuǎn)賬到收單銀行商家?guī)ぬ?hào)，支付網(wǎng)關(guān)通過金融專網(wǎng)完成轉(zhuǎn)賬后，生成取款應(yīng)答消息發(fā)送給商家。

在以上的工作步驟當(dāng)中，持卡人、商家和支付網(wǎng)關(guān)都通過CA來認(rèn)證通信主體的身份，以確保通信的對(duì)方不是冒名頂替。

2、SET提供的功能

(1)所有信息在Internet上加密安全傳輸，保證數(shù)據(jù)不會(huì)被他人竊取。

(2)數(shù)字簽名保證信息的完整性和不可否認(rèn)性。

(3)訂單信息和個(gè)人信用卡信息的隔離，使商家看不到客戶的信用卡信息。

(4)參與交易各方的身份認(rèn)證，保證各方身份不可假冒。

三、SSL與SET的比較

SET是一個(gè)多方面的消息報(bào)文協(xié)議，它定義了銀行、商家、客戶之間必須符合的報(bào)文規(guī)范。SSL只是簡(jiǎn)單地在客戶端與服務(wù)器之間建立了一個(gè)安全傳輸通道，在涉及多方的電子交易中，只能提供交易中客戶端與服務(wù)器間的認(rèn)證，其并不具備商務(wù)性、服務(wù)性和集成性。SET報(bào)文能夠在銀行內(nèi)部網(wǎng)絡(luò)或其他網(wǎng)絡(luò)傳輸，而SSL之上的支付系統(tǒng)只能與Web瀏覽器捆綁在一起。除此之外，它們還有以下區(qū)別：

1、認(rèn)證機(jī)制方面，SET的安全需求較高，因此所有參與SET交易的成員都必須先申請(qǐng)數(shù)字證書來識(shí)別身份，而在SSL中只有商家服務(wù)器需要認(rèn)證，客戶端認(rèn)證是可選的。

2、對(duì)客戶而言，SET保證了商家的合法性，并且用戶的信用卡號(hào)不會(huì)被竊取。SET替客戶保守了更多的秘密使其在線購物更加輕松。在SSL協(xié)議中則缺少對(duì)商家的認(rèn)證。

3、安全性上，SET的安全性較SSL高，主要原因是在整個(gè)交易中，包括客戶到商家、商家到支付網(wǎng)關(guān)再到銀行都受到嚴(yán)密的保護(hù)。而SSL的安全范圍只限于客戶到商家的信息交流。

四、結(jié)論

總的來講，由于SSL協(xié)議的成本低、速度快、使用簡(jiǎn)單，對(duì)現(xiàn)有網(wǎng)絡(luò)系統(tǒng)不需進(jìn)行大的修改，因而其應(yīng)用也相對(duì)較廣泛。目前我國已有多家銀行采用SSL協(xié)議，開展網(wǎng)上銀行業(yè)務(wù)。SET協(xié)議比較復(fù)雜，它還要求在銀行網(wǎng)絡(luò)、商家服務(wù)器、客戶端的PC上安裝相應(yīng)的軟件，此外還要求必須向各方發(fā)放數(shù)字證書。這些都阻止了SET的廣泛發(fā)展。但從安全性角度看，SSL協(xié)議不如SET協(xié)議安全，對(duì)于使用信用卡支付的系統(tǒng)來說，SET協(xié)議是最好的選擇。

結(jié)合我國的具體情況，可以預(yù)見，電子商務(wù)安全措施在我國的發(fā)展趨勢(shì)將是SET與SSL共存，優(yōu)勢(shì)互補(bǔ)。即在商家與銀行之間采用SET協(xié)議，而與顧客連接時(shí)仍然使用SSL協(xié)議。這種方案既回避了在顧客端機(jī)器上安裝軟件。同時(shí)又可獲得了SET提供的很多優(yōu)點(diǎn)（作者單位：溫州醫(yī)學(xué)院計(jì)算機(jī)教研室）

第三篇：什么是SSL安全協(xié)議

什么是SSL安全協(xié)議

SSL安全協(xié)議最初是由Netscape Communication公司設(shè)計(jì)開發(fā)的，又叫“安全套接層(Secure Sockets Layer)協(xié)議”，主要用于提高應(yīng)用程序之間數(shù)據(jù)的安全系數(shù)。SSL協(xié)議的整個(gè)概念可以被總結(jié)為：一個(gè)保證任何安裝了安全套接字的客戶和服務(wù)器間事務(wù)安全的協(xié)議，它涉及所有TC/IP應(yīng)用程序。

SSL安全協(xié)議主要提供三方面的服務(wù)：

用戶和服務(wù)器的合法性認(rèn)證

認(rèn)證用戶和服務(wù)器的合法性，使得它們能夠確信數(shù)據(jù)將被發(fā)送到正確的客戶機(jī)和服務(wù)器上?？蛻魴C(jī)和服務(wù)器都是有各自的識(shí)別號(hào)，這些識(shí)別號(hào)由公開密鑰進(jìn)行編號(hào)，為了驗(yàn)證用戶是否合法，安全套接層協(xié)議要求在握手交換數(shù)據(jù)時(shí)進(jìn)行數(shù)字認(rèn)證，以此來確保用戶的合法性。

加密數(shù)據(jù)以隱藏被傳送的數(shù)據(jù)

安全套接層協(xié)議所采用的加密技術(shù)既有對(duì)稱密鑰技術(shù)，也有公開密鑰技術(shù)。在客戶機(jī)與服務(wù)器進(jìn)行數(shù)據(jù)交換之前，交換SSL初始握手信息，在SSL握手情息中采用了各種加密技術(shù)對(duì)其加密，以保證其機(jī)密性和數(shù)據(jù)的完整性，并且用數(shù)字證書進(jìn)行鑒別，這樣就可以防止非法用戶進(jìn)行破譯。

保護(hù)數(shù)據(jù)的完整性

安全套接層協(xié)議采用Hash函數(shù)和機(jī)密共享的方法來提供信息的完整性服務(wù)，建立客戶機(jī)與服務(wù)器之間的安全通道，使所有經(jīng)過安全套接層協(xié)議處理的業(yè)務(wù)在傳輸過程中能全部完整準(zhǔn)確無誤地到達(dá)目的地。

安全套接層協(xié)議是一個(gè)保證計(jì)算機(jī)通信安全的協(xié)議，對(duì)通信對(duì)話過程進(jìn)行安全保護(hù)，其實(shí)現(xiàn)過程主要經(jīng)過如下幾個(gè)階段：

1.接通階段：客戶機(jī)通過網(wǎng)絡(luò)向服務(wù)器打招呼，服務(wù)器回應(yīng);

2.密碼交換階段：客戶機(jī)與服務(wù)器之間交換雙方認(rèn)可的密碼，一般選用RSA密碼算法，也有的選用Diffie-Hellmanf和Fortezza-KEA密碼算法;

3.會(huì)談密碼階段：客戶機(jī)器與服務(wù)器間產(chǎn)生彼此交談的會(huì)談密碼;

4.檢驗(yàn)階段：客戶機(jī)檢驗(yàn)服務(wù)器取得的密碼;

5.客戶認(rèn)證階段：服務(wù)器驗(yàn)證客戶機(jī)的可信度;

6.結(jié)束階段：客戶機(jī)與服務(wù)器之間相互交換結(jié)束的信息。

當(dāng)上述動(dòng)作完成之后，兩者間的資料傳送就會(huì)加密，另外一方收到資料后，再將編碼資料還原。即使盜竊者在網(wǎng)絡(luò)上取得編碼后的資料，如果沒有原先編制的密碼算法，也不能獲得可讀的有用資料。

發(fā)送時(shí)信息用對(duì)稱密鑰加密，對(duì)稱密鑰用非對(duì)稱算法加密，再把兩個(gè)包綁在一起傳送過去。

接收的過程與發(fā)送正好相反，先打開有對(duì)稱密鑰的加密包，再用對(duì)稱密鑰解密。在電子商務(wù)交易過程中，由于有銀行參與，按照SSL協(xié)議，客戶的購買信息首先發(fā)往商家，商家再將信息轉(zhuǎn)發(fā)銀行，銀行驗(yàn)證客戶信息的合法性后，通知商家付款成功，商家再通知客戶購買成功，并將商品寄送客戶。

本文由：ev ssl證書 http://verisign.itrus.com.cn/ 整理

第四篇：計(jì)算機(jī)信息安全論文：基于SET協(xié)議的移動(dòng)支付安全的分析與改進(jìn)

計(jì)算機(jī)信息安全論文：基于SET協(xié)議的移動(dòng)支付安全的分析與改進(jìn)

摘要:分析了在WAP環(huán)境下基于SET協(xié)議的移動(dòng)支付的交易流程不滿足商品原子性和確認(rèn)發(fā)送原子性。當(dāng)商家得到正確支付后,SET協(xié)議不能保證他一定會(huì)發(fā)貨給持卡者,也不能保證發(fā)送的就是持卡者訂購的商品。同時(shí)基于SET協(xié)議的安全性和不可否認(rèn)性也存在著不足。基于這些局限性,本文通過加入預(yù)付款機(jī)制,信用等級(jí)制度和糾紛仲裁機(jī)制,完善了移動(dòng)支付的整個(gè)交易過程,切實(shí)保護(hù)了各方的利益。

關(guān)鍵詞:SET協(xié)議;移動(dòng)支付;原子性;信用等級(jí)制度;WAP 1引言

移動(dòng)支付業(yè)務(wù)是由移動(dòng)運(yùn)營(yíng)商、服務(wù)提供商和金融機(jī)構(gòu)共同推出的、構(gòu)建在移動(dòng)運(yùn)營(yíng)支撐系統(tǒng)上的一個(gè)移動(dòng)數(shù)據(jù)增值業(yè)務(wù)。通過移動(dòng)支付,企業(yè)和用戶可以隨時(shí)隨地通過無線方式進(jìn)行交易,大大增強(qiáng)了買賣雙方的靈活性和支付性。中國擁有廣大的移動(dòng)用戶群,而且這些移動(dòng)用戶都是收入較高者,擁有比較強(qiáng)的消費(fèi)能力,綜合這些方面,中國的手機(jī)支付業(yè)務(wù)具有相當(dāng)大的發(fā)展?jié)摿?。但是移?dòng)支付目前的發(fā)展?fàn)顩r并不像預(yù)期的那么好,安全性、技術(shù)平臺(tái)有待成熟、完善和標(biāo)準(zhǔn)化,消費(fèi)者缺乏使用習(xí)慣,信用體系的缺失等幾個(gè)問題是阻礙移動(dòng)支付發(fā)展的主要因素。其中移動(dòng)支付的安全問題又是建立一個(gè)完善的移動(dòng)電子支付系統(tǒng)所要解決的首要問題。只要手機(jī)支付在信用安全方面的問題得不到有效地解決,移動(dòng)支付就很難得到真正的應(yīng)用。因此,可以采

用先進(jìn)的技術(shù)和設(shè)備來確保移動(dòng)支付的安全性問題?，F(xiàn)有的信息安全基礎(chǔ)技術(shù)為移動(dòng)支付的安全保障提供了非常有力的解決途徑。其中身份認(rèn)證、數(shù)據(jù)加密、數(shù)字簽名等技術(shù)是移動(dòng)安全支付系統(tǒng)中最重要的基礎(chǔ)技術(shù)。

2移動(dòng)支付中的安全威脅和安全要求 2.1移動(dòng)支付面臨的三大安全威脅(1)交易者身份被冒用。

(2)傳輸交易資料(付款卡或賬號(hào)等私人資料)時(shí)被竊取或修改。(3)交易者否認(rèn)曾經(jīng)進(jìn)行過的交易。

2.2移動(dòng)支付的安全要求移動(dòng)支付應(yīng)對(duì)支付本身、支付所涉及的內(nèi)容進(jìn)行恰當(dāng)?shù)谋Ｗo(hù),確保交易雙方的合法權(quán)益不受非法攻擊者的侵害。通常移動(dòng)支付應(yīng)滿足下面的安全要求:(1)交易雙方身份的認(rèn)證。(2)資料信息的私密性。(3)資料信息的一致性、完整性。(4)不可否認(rèn)性。SET協(xié)議在移動(dòng)支付中的應(yīng)用

3.1 WAP環(huán)境分析WAP網(wǎng)絡(luò)架構(gòu)由3部分組成,即WAP網(wǎng)關(guān)、移動(dòng)終端和WAP源服務(wù)器。WAP網(wǎng)關(guān)起著“翻譯”的作用,是聯(lián)系GSM網(wǎng)和Internet的橋梁;移動(dòng)終端為用戶提供了上網(wǎng)用的微瀏覽器以及信息命令的輸入方式;WAP源服務(wù)器存儲(chǔ)大量信息,以提供移動(dòng)

終端用戶瀏覽和查詢。

WAP以WTLS協(xié)議作為傳輸層安全協(xié)議,保證在WAP網(wǎng)關(guān)和移動(dòng)終端之間安全連接。在有線環(huán)境下用SSL協(xié)議用來保證WAP網(wǎng)關(guān)和Internet Web服務(wù)器之間的安全通信。

但是由于WAP移動(dòng)終端內(nèi)存小、處理能力低和無線網(wǎng)絡(luò)帶寬窄等局限性,并且SET協(xié)議在提出之時(shí)沒有考慮無線通訊環(huán)境。要解決上述問題,可以將SET協(xié)議中的傳統(tǒng)電子錢包進(jìn)行優(yōu)化。將原來主要功能集于一身的“胖”電子錢包分為兩部分:電子錢包服務(wù)器端和電子錢包客戶端。客戶端是一個(gè)很小的瀏覽器插件,可以安裝在移動(dòng)終端,服務(wù)器端承擔(dān)了大部分的處理交易功能。這樣改進(jìn)后的SET協(xié)議就可以用于WAP環(huán)境下的移動(dòng)支付。

3.2支持WAP終端的SET模型

電子錢包接口安裝在WAP終端,服務(wù)器錢包代表持卡人與器錢包之間采用WAP的WTLS和SSL安全協(xié)議,實(shí)現(xiàn)兩者之間的安全通訊。

3.3基于SET協(xié)議的移動(dòng)支付交易流程

(1)持卡者使用微瀏覽器登陸商家網(wǎng)上商城購物,選定要購買的商品放入購物車,完畢后,點(diǎn)擊“支付”按鈕;(2)商家軟件生成包含商品、價(jià)格、交易碼在內(nèi)的訂單信息,啟動(dòng)電子錢包客戶端,輸入用戶名稱和密碼登錄,與錢包服務(wù)器端開始一個(gè)WTLS會(huì)話連接;(3)服務(wù)器錢包發(fā)出它的WTLS證書給錢包客戶端。一旦錢包客

戶端驗(yàn)證通過,就開始發(fā)送初始交易信息;(4)客戶端錢包接口將支付初始消息發(fā)向服務(wù)器錢包,選擇卡種來進(jìn)行付款;(5)服務(wù)器電子錢包向商家發(fā)送初始化請(qǐng)求;(6)商家發(fā)送初始化響應(yīng)及證書;(7)服務(wù)器電子錢包收到響應(yīng),產(chǎn)生購買請(qǐng)求發(fā)送給商家,同時(shí)包括支付網(wǎng)關(guān)需要的信息;(8)商家收到購買請(qǐng)求后,向支付網(wǎng)關(guān)發(fā)送授權(quán)請(qǐng)款請(qǐng)求(9)支付網(wǎng)關(guān)收到授權(quán)請(qǐng)款請(qǐng)求后,產(chǎn)生授權(quán)請(qǐng)款響應(yīng)發(fā)送給商家;(10)商家處理授權(quán)請(qǐng)款響應(yīng),發(fā)送購物請(qǐng)求響應(yīng)給服務(wù)器電子錢包,并發(fā)送客戶購買的貨物或服務(wù);(11)服務(wù)器電子錢包與顧客客戶端WTLS會(huì)話連接,通知客戶端支付成功。

3.4基于SET協(xié)議的移動(dòng)支付的局限性

雖然能夠解決WAP終端和電子錢包服務(wù)器端的安全連接和身份認(rèn)證問題,但是由于SET協(xié)議交易流程中本身存在著缺陷,移動(dòng)支付交易也存在著同樣的局限性。

(1)業(yè)務(wù)信息保密和完整性:終端用戶發(fā)出的支付敏感數(shù)據(jù)可能被泄露,支付數(shù)據(jù)可能未經(jīng)用戶同意被篡改。

(2)不可否認(rèn)性:終端用戶否認(rèn)他所發(fā)的信息或商家否認(rèn)他接受的消息,交易發(fā)生糾紛時(shí),將無法辨別糾紛中的是與非。

(3)商品的原子性和交易原子性:不能保證商家一定會(huì)發(fā)貨給持卡者,也不能保證發(fā)送的就是持卡者訂購的商品。

(4)缺少信用機(jī)制:商家和顧客對(duì)各自互不了解,尤其是持卡者對(duì)商家的信用度并不明確,因而承受一定的信用風(fēng)險(xiǎn)。

4基于高級(jí)SET協(xié)議的移動(dòng)支付交易流程

(1)客戶端錢包與服務(wù)器錢包建立連接,完成初始化通信。(2)服務(wù)器錢包代表持卡人C(Cardholder)、商家B(Business)和支付網(wǎng)關(guān)(Gateway)在交易開始之前,獲得彼此可信的證書。并且終端用戶通過合法身份到發(fā)卡行注冊(cè)虛擬的用戶名和虛擬賬號(hào)。

(3)錢包服務(wù)器端接收到客戶端發(fā)送的購買基本信息,包括購買的商品、交易支付卡品牌、相應(yīng)的服務(wù)信息,將訂單請(qǐng)求用商家的公鑰PKB(Public Key of Business)加密發(fā)送到商家。

(4)B用自己的私鑰SKB(Secret Key of Business)解密持卡者C的訂單,并根據(jù)現(xiàn)貨和庫存給出報(bào)價(jià)單,用SKB加密傳給S。

(5)持卡者用商家和用戶的信用等級(jí)來確定預(yù)付款。信用評(píng)價(jià)機(jī)構(gòu)將商家和用戶的信用等級(jí)分為五類(A~E),每個(gè)等級(jí)對(duì)應(yīng)一個(gè)信用百分?jǐn)?shù)和懷疑百分?jǐn)?shù)。要確定一個(gè)預(yù)付款百分?jǐn)?shù)P(Percent),得到的公式:假設(shè)商家信用度為B級(jí),持卡者信用度為C級(jí),則預(yù)付款百分?jǐn)?shù)p=(80%+30%)/(90%+50%)=78.6%。將預(yù)付款百分?jǐn)?shù)乘以報(bào)價(jià)即可得到預(yù)付款額M1和后付款額M2。假設(shè)報(bào)價(jià)為5000,預(yù)付款百分?jǐn)?shù)為

78.6%,預(yù)付款M1=3930,后付款額M2=5000–3930=1070。持卡者C數(shù)字簽名M′=ESKC(GradeC,GradeB,M1,M2,O),同時(shí)用PKB加密M′和DCC(Digital Certificateof C)得到M″=EPKB(M′,DCC),并發(fā)送給商家。

(6)商家用SKB解密得到DCC,然后到CA中心驗(yàn)證其真實(shí)無誤,則用PKC(Public Key of C)解密M′得到GradeC,GradeB,M1,M2,O。商家用同樣的、雙方約定的規(guī)則確定出首付款和后付款與持卡者發(fā)送來的相比較,正確無誤后,商家用Hash算法對(duì)隨機(jī)生成的一個(gè)對(duì)稱密鑰K1,交易號(hào)N的訂單O運(yùn)算得到O′,再用K1對(duì)(O′,M1,M2,N)加密得R=EK1(O′,M1,M2,N),然后用PKC對(duì)K1加密得K1′,再數(shù)字簽名得Q=ESKB(R,K1′),將Q發(fā)送給持卡者。同時(shí)用支付網(wǎng)關(guān)的公鑰PKG加密K1得K1″,然后數(shù)字簽名得Q′=ESKB(R,K1″),發(fā)送給支付網(wǎng)關(guān)。

(7)C對(duì)Q解密,確定是由商家發(fā)來,并用SKC解密K1′,得到K1并用來解密R,得到O′,M1,M2,N,對(duì)照確定無誤后,持卡者產(chǎn)生支付指令PI(Payment Instructions),其中包括M1和M2等,并對(duì)PI進(jìn)行數(shù)字簽名PI′=ESKC(PI)。持卡者隨機(jī)生成一個(gè)對(duì)稱密鑰K2,并對(duì)PI′進(jìn)行加密PI″=EK2(PI′),對(duì)訂單O進(jìn)行Hash運(yùn)算得O″。用C的密鑰K2對(duì)其虛擬賬戶信息VAI進(jìn)行加密得VAI′=EK2(VAI),用支付網(wǎng)關(guān)的公鑰加密K2得K2′=ESKG(K2)。這樣防止了商家獲悉持卡者的有關(guān)支付信息,只有支付網(wǎng)關(guān)G才可以解密。持卡者對(duì)自己的數(shù)字證

書DCC以及PI″,K2′,O″,VAI′進(jìn)行數(shù)字簽名,T=ESKC(DCC,PI″,K2′,O″,VAI′),然后將T發(fā)送給商家。

(8)商家對(duì)收到的T解密,確定是由C發(fā)來,然后對(duì)DCC,I″,其他SET實(shí)體(商家、支付網(wǎng)關(guān)、CA)進(jìn)行通訊,WAP終端和服務(wù)K2′,O″,VAI′進(jìn)行數(shù)字簽名發(fā)送到支付網(wǎng)關(guān)。

(9)支付網(wǎng)關(guān)對(duì)其用PKB進(jìn)行解密,確定是由商家發(fā)來,對(duì)得到的DCC到CA進(jìn)行驗(yàn)證,驗(yàn)證成功,用PKG(Public Key ofGateway)解密K2′得到K2并解密PI″,VAI′,PI′得到VAI和簽了名的PI′和PI。將O′與O″對(duì)照,商家所發(fā)M1,M2與持卡者所發(fā)M1,M2對(duì)照,無誤則將支付指令PI和VAI經(jīng)由金融專用網(wǎng)發(fā)給發(fā)卡行。

(10)發(fā)卡行進(jìn)行驗(yàn)證確定持者信息無誤,發(fā)生資金劃撥M1并將M2凍結(jié),發(fā)送完成消息和銀行交易序列號(hào)NUM到支付網(wǎng)關(guān)。

(11)G向B發(fā)送支付已訖消息OK和NUM,用PKB加密并數(shù)字簽名發(fā)送給商家。

(12)B用PKG和SKB解密,確認(rèn)為G所發(fā)并確認(rèn)已付信息;然后向C發(fā)出發(fā)貨通知,并用PKC加密后數(shù)字簽名發(fā)往C。

(13)當(dāng)C確認(rèn)所購物品無誤,用PKC將收到消息加密簽名后發(fā)送到商家,同時(shí)發(fā)出二次支付指令PI2解凍M2并將之劃歸商家等。驗(yàn)證加密流程同指令PI1。若在一定期限內(nèi)雙方無異議,則M2將自動(dòng)劃撥到商家賬號(hào)。

(14)若C發(fā)現(xiàn)商品并不是自己所購商品或物品損壞或商家欺詐行

為,首先提出與商家協(xié)商,協(xié)商未果則在M2自動(dòng)解凍期內(nèi)向G發(fā)送調(diào)解請(qǐng)求,G將再次凍結(jié)或延長(zhǎng)M2凍結(jié)期,同時(shí)仲裁機(jī)構(gòu)介入,作出判決。并向信用等級(jí)評(píng)價(jià)機(jī)構(gòu)發(fā)出指令給與敗訴方相應(yīng)懲罰,如降低敗訴方的信用等級(jí)等。

5安全性分析

(1)機(jī)密性在協(xié)議信息傳輸時(shí),支付終端對(duì)發(fā)送信息中與支付相關(guān)的敏感信息如支付賬號(hào)、支付密碼等使用會(huì)話密鑰進(jìn)行加密,保證了在無線通信環(huán)境下這些敏感信息的機(jī)密性。

(2)完整性使用Hash算法進(jìn)行了數(shù)字摘要,保證了數(shù)據(jù)的完整性。(3)不可否認(rèn)性每次信息傳輸發(fā)送方與接收方都要進(jìn)行數(shù)字證書的驗(yàn)證以保證其身份真實(shí),并且商家要驗(yàn)證客戶所發(fā)訂單以及款項(xiàng),支付網(wǎng)關(guān)驗(yàn)證雙方的訂單摘要、付款金額。本支付流程中移動(dòng)終端并不直接簽名,由發(fā)卡行的錢包服務(wù)器端對(duì)其認(rèn)證,代其簽名。所有傳輸?shù)臄?shù)據(jù)商家、持卡者的錢包服務(wù)器端、支付網(wǎng)關(guān)都有數(shù)據(jù)證據(jù)和雙方確認(rèn)信息。

(4)交易原子性和商品原子性商品的訂單是雙方確定的,不可抵賴,且支付網(wǎng)關(guān)有訂單的摘要,確保發(fā)送商品確實(shí)是持卡者所要的。當(dāng)客戶發(fā)現(xiàn)非己所要的商品,可向商家協(xié)商或向仲裁機(jī)構(gòu)投訴,保證商品發(fā)送原子性。通過建立預(yù)付款機(jī)制有效避免了客戶利益的損失。如果客戶發(fā)現(xiàn)商家延遲發(fā)貨或者商品在到達(dá)客戶手中已經(jīng)損壞,客戶可向仲裁機(jī)構(gòu)投訴責(zé)令商家承擔(dān)責(zé)任,降低商家信用等級(jí),保證滿足商品原子

性。

(5)可信性信用制度的引進(jìn)約束了商家和持卡人的行為,減少了可能的欺詐行為,增加了移動(dòng)電子商務(wù)交易的可信度。首付與后付款的采用保護(hù)了持卡人的利益,避免商家的抵賴,欺詐與發(fā)貨不及時(shí)性問題,以及物品中途受損給持卡人造成的利益損害。

6結(jié)束語

本文作者創(chuàng)新觀點(diǎn):本文在分析了移動(dòng)支付的安全要求后,在WAP環(huán)境下,針對(duì)原有的基于SET協(xié)議的移動(dòng)支付方案的缺陷,引進(jìn)電子錢包客戶端與電子錢包服務(wù)器端,解決了WAP移動(dòng)終端內(nèi)存小等局限性;并通過建立預(yù)付款機(jī)制、仲裁機(jī)構(gòu)、信用等級(jí)制度等有效地解決交易中的公平性、原子性、不可否認(rèn)性和安全性等問題。

參考文獻(xiàn)

[1]Liang Jin,Shi Ren.Research on WAP Clients Supports SETpayment protocol[J].Xi’an Jiaotong Univ 2002.08

[2]李北金,張力.基于WAP的電子支付的安全性研究[J].微計(jì)算機(jī)信息.2008.06 [3]汪楊琴.移動(dòng)支付協(xié)議安全性研究.上海交通大學(xué)[D].中國優(yōu)秀碩士學(xué)位論文全文數(shù)據(jù)庫.2007 [4]張若巖.基于SET協(xié)議的移動(dòng)支付系統(tǒng)的研究與實(shí)現(xiàn)[D].西北工業(yè)大學(xué).中國優(yōu)秀碩士學(xué)位論文全文數(shù)據(jù)庫.2008 [5]Mobile Payment Forum,ltd.Mobile Payment Forum White

Paper.http://004km.cn/mpf_member_news_and_events/mpf_documents/Mobile_Payment_Forum_White_Paper_December_2002.pdf [6]李峰.移動(dòng)支付安全研究[D].山東大學(xué)。中國優(yōu)秀碩士學(xué)位論文全文數(shù)據(jù)庫.2008作者簡(jiǎn)介:萬仲保(1965-),男(漢族),江西南昌,華東交通大學(xué)副教授,研究方向:信息安全,網(wǎng)絡(luò)工程;王晴(1984-),女(漢族),江蘇南京,華東交通大學(xué)碩士研究生,研究方向:信息安全,移動(dòng)支付安全

－

第五篇：SSL(Secure Sockets Layer)協(xié)議與數(shù)字證書

SSL（Secure Sockets Layer）協(xié)議與數(shù)字證書 SSL的概述

由于 Web上有時(shí)要傳輸重要或敏感的數(shù)據(jù)，Netscape公司在推出 Web瀏覽器首版的同時(shí)，提出了安全通信協(xié)議 SSL（Secure Socket Layer）。

目的是在 Internet基礎(chǔ)上提供一種基于會(huì)話加密和認(rèn)證的安全協(xié)議。SSL協(xié)議已成為 Internet上保密通訊的工業(yè)標(biāo)準(zhǔn)?，F(xiàn)行 Web瀏覽器普遍將 HTTP和 SSL相結(jié)合，從而實(shí)現(xiàn)安全通信。

SSL協(xié)議有以下三個(gè)特性 : 保密性。因?yàn)樵谖帐謪f(xié)議定義了會(huì)話密鑰后，所有的消息都被加密。

確認(rèn)性。因?yàn)楸M管會(huì)話的客戶端認(rèn)證是可選的，但是服務(wù)器端始終是被認(rèn)證的?？煽啃?。因?yàn)閭魉偷南ㄏ⑼暾詸z查（使用 MAC）。

SSL或 TSL工作在 TCP層與 HTTP,FTP,SMTP之間.2 SSL的體系結(jié)構(gòu)

SSL協(xié)議分為兩層協(xié)議。

一層是 SSL記錄協(xié)議（SSL Record Protocol），它建立在可靠的傳輸協(xié)議（如 TCP）之上，為更高層提供基本的安全服務(wù)，如提供數(shù)據(jù)封裝、壓縮、加密 等基本功能的支持。

另一層是建立在 SSL記錄協(xié)議之上，用于在實(shí)際的數(shù)據(jù)傳輸開始前，通訊雙方進(jìn)行身份認(rèn)證、協(xié)商加密算法、交換加密密鑰等。它由三個(gè)協(xié)議組成：

? SSL握手協(xié)議（SSL Handshake Protocol）

? SSL修改密文規(guī)約協(xié)議（SSL Change Cipher Spec Protocol）? SSL告警協(xié)議（SSL Alert Protocol）

圖：SSL 協(xié)議棧

SSL中協(xié)議中兩個(gè)重要概念 ：

SSL連接（connection）：在 OSI分層模型的定義中，連接是提供一種合適類型服務(wù)的傳輸。而 SSL的連接是點(diǎn)對(duì)點(diǎn)的關(guān)系。連接是暫時(shí)的，每一個(gè)連接和一個(gè)會(huì)話關(guān)聯(lián)。

SSL會(huì)話（session）：一個(gè) SSL會(huì)話是在客戶與服務(wù)器之間的一個(gè)關(guān)聯(lián)。會(huì)話由握手協(xié)議創(chuàng)建。會(huì)話定義了一組可供多個(gè)連接共享的加密安全參數(shù)。會(huì)話用以避免為每一個(gè)連接提供新的安全參數(shù)所付出昂貴的代價(jià)。

① 會(huì)話狀態(tài) 由下列參數(shù)定義：

? 會(huì)話標(biāo)識(shí)符 ：服務(wù)器選擇的一個(gè)任意字節(jié)序列，用以標(biāo)識(shí)一個(gè)活動(dòng)的或可激活的會(huì)話狀態(tài)。

? ? ? 對(duì)方證書 ：一個(gè) X.509.v3證書?？蔀榭?。

壓縮方法 ：加密前進(jìn)行數(shù)據(jù)壓縮的算法。

密文規(guī)約 ：指明數(shù)據(jù)體加密的算法（無，或 DES等），以及用以計(jì)算 MAC散列算法（如 MD5或 SHA-1）。還包括其它參數(shù)，如散列長(zhǎng)度，主密碼（48位 C與 S之間共享的密鑰），重新開始標(biāo)志（指明該會(huì)話是否能用于產(chǎn)生一個(gè)新連接）。

② 連接狀態(tài) 由下列參數(shù)定義：

? ? ? 服務(wù)器和客戶的隨機(jī)數(shù)：服務(wù)器和客戶為每一個(gè)連接所選擇的字節(jié)序列。

服務(wù)器寫 MAC密碼：一個(gè)密鑰，用來對(duì)服務(wù)器發(fā)送的數(shù)據(jù)進(jìn)行 MAC操作。

客戶寫 MAC密碼：一個(gè)密鑰，用來對(duì)客戶發(fā)送的數(shù)據(jù)進(jìn)行 MAC操作。? 服務(wù)器寫密鑰：用于服務(wù)器進(jìn)行數(shù)據(jù)加密，客戶進(jìn)行數(shù)據(jù)解密的對(duì)稱加密密鑰；

? 客戶寫密鑰：用于客戶進(jìn)行數(shù)據(jù)加密，服務(wù)器 r進(jìn)行數(shù)據(jù)解密的對(duì)稱加密密鑰；

? 初始化向量：當(dāng)數(shù)據(jù)加密采用 CBC方式時(shí)，每一個(gè)密鑰保持一個(gè) IV。該字段首先由 SSL握手協(xié)議初始化，以后保留每次最后的密文數(shù)據(jù)塊作為下一個(gè)記錄的 IV。

? 序號(hào)：每一方為每一個(gè)連接的數(shù)據(jù)發(fā)送與接收維護(hù)單獨(dú)的順序號(hào)。當(dāng)一方發(fā)送或接收一個(gè)修改的密文規(guī)約的報(bào)文時(shí)，序號(hào)置為 0，最大 264-1。SSL記錄協(xié)議

在 SSL協(xié)議中，所有的傳輸數(shù)據(jù)都被封裝在記錄中。記錄是由記錄頭和長(zhǎng)度不為 0的記錄數(shù)據(jù)組成的。所有的 SSL通信包括握手消息、安全空白記錄和應(yīng)用數(shù)據(jù)都使用 SSL記錄層。SSL記錄協(xié)議（SSL Record Protocol）包括了記錄頭和記錄數(shù)據(jù)格式的規(guī)定。

1.SSL記錄頭格式

SSL的記錄頭可以是兩個(gè)或三個(gè)字節(jié)長(zhǎng)的編碼。SSL記錄頭的包含的信息包括：記錄頭的長(zhǎng)度、記錄數(shù)據(jù)的長(zhǎng)度、記錄數(shù)據(jù)中是否有粘貼數(shù)據(jù)。2.SSL記錄數(shù)據(jù)的格式

SSL的記錄數(shù)據(jù)包含三個(gè)部分： MAC(Message Authentication Code)數(shù)據(jù)、實(shí)際數(shù)據(jù)和粘貼數(shù)據(jù)。

3.SSL記錄協(xié)議操作

在 SSL的記錄層完成對(duì)數(shù)據(jù)加密、解密和認(rèn)證。操作過程如圖所示：

SSL Record Protocol

All SSL protocol messages move in records of up to 32,767 bytes.Each message has a header of either 2 or 3 bytes.The headers include a security escape function, a flag to indicate the existence of padding, and the length of the message(and possibly the padding.)A two byte header has no padding, a three byte header includes some padding.The meaning of bits is as follows:

8

+----------------+-----------------+----------------+

|# S Length | Length | Padding length |

+----------------+-----------------+----------------+

# is the number of bytes in the header

0 indicates a 3 byte header, max length 32,767 bytes.1 indicates a 2 byte header, max length 16,383 bytes S

indicates the presence of a security escape, although none are

currently implemented.(Several suggestions for security

escapes are in the weaknesses section.)

There is no version information within the SSL record header, although it is available in the handshake.Within a record, there are three components: MAC-DATA, Actual-data, and Padding-data.MAC is the Message Authentication Code , Actual-data is the actual data being sent, and Padding-data is padding.The MAC-DATA is a hash of a key, the data, padding, and a sequence number.The hash is chosen based on the cipher-choice.The key used is the(sender)-write-key, which is the same key as the(receiver)-read-key.When cipher-choice is not defined, there is no mac-data or padding-data.Padding is used to ensure that the data is a multiple of the block size when a block cipher is used.Padding data is always discarded after the MAC has been calculated.Sequence numbers are unsigned 32 bit integers incremented with each message sent.Sequence numbers wrap to zero after 0xFFFFFFFF.Each dialog direction has its own sequence number.Failure to authenticate, decrypt, or otherwise get correct answers in a crytpographic operation result in I/O errors, and a close of connection.附： 主 密碼的計(jì)算

主秘密(master secret)的生成，它是從預(yù)主秘密衍生出來的。當(dāng)生成了一個(gè)預(yù)主秘密并且雙方都知道它之后，就可以計(jì)算主秘密，用作共享秘密的主秘密是通過對(duì)許多先前的消息交接中的數(shù)據(jù)的雜湊計(jì)算構(gòu)成的。

生成主密鑰這些計(jì)算格式如下： Master_secret= MD5（pre-master-secret+SHA（A+pre-master-secre+ClientHello.random+ServerHello.random））+ MD5（pre-master-secret+SHA（BB+pre-master-secre+ClientHello.random+ ServerHello.random））+ MD5（pre-master-secret+SHA（BB+pre-master-secre+ClientHello.random+ ServerHello.random））修改密文規(guī)約協(xié)議

修改密文規(guī)約協(xié)議（SSL Change Cipher Spec Protocol）是簡(jiǎn)單的特定 SSL的協(xié)議。

目的：為表示密碼策略的變化。該協(xié)議包括一個(gè)單一的消息，它由記錄層按照密碼規(guī)約中所指定的方式進(jìn)行加密和壓縮。在完成握手協(xié)議之前，客戶端和服務(wù)器都要 發(fā)送這一消息，以便通知對(duì)方其后的記錄將用剛剛協(xié)商的密碼規(guī)范以及相關(guān)聯(lián)的密鑰來保護(hù)。所有意外的更改密碼規(guī)范消息都將生成一個(gè) “意外消息（unexpected_message）”警告。告警協(xié)議 警告協(xié)議將警告消息以及它們的嚴(yán)重程度傳遞給 SSL會(huì)話中的主體。就像由記錄層處理的應(yīng)用層數(shù)據(jù)一樣，警告消息也用當(dāng)前連接狀態(tài)所指定的方式來壓縮和加密。

當(dāng)任何一方檢測(cè)到一個(gè)錯(cuò)誤時(shí)，檢測(cè)的一方就向另一方發(fā)送一個(gè)消息。如果警告消息有一個(gè)致命的后果，則通信的雙方應(yīng)立即關(guān)閉連接。雙方都需要忘記任何與該失敗的連接相關(guān)聯(lián)的會(huì)話標(biāo)識(shí)符、密鑰和秘密。對(duì)于所有的非致命錯(cuò)誤，雙方可以緩存信息以恢復(fù)該連接。握手協(xié)議

SSL握手協(xié)議負(fù)責(zé)建立當(dāng)前會(huì)話狀態(tài)的參數(shù)。雙方協(xié)商一個(gè)協(xié)議版本，選擇密碼算法，互相認(rèn)證（不是必需的），并且使用公鑰加密技術(shù)通過一系列交換的消息在客戶端和服務(wù)器之間生成共享密鑰。

SSL握手協(xié)議動(dòng)作包含四個(gè)階段。握手協(xié)議的動(dòng)作如圖所示。

第一階段 建立安全能力（1）Client Hello消息（2）Server Hello消息 第二階段 服務(wù)器認(rèn)證和密鑰交換

（1）Server Certificate消息（2）Server Key Exchange消息（3）Certificate Request消息（4）Server Hello Done消息 第三階段 客戶認(rèn)證和密鑰交換（1）Client Certificate消息（2）Client Key Exchange消息（3）Certificate Verify消息 第四階段 結(jié)束握手

（1）Change Cipher Spec 消息（2）Finished消息

（3）Change Cipher Spec 消息（4）Finished消息

握手交互流程：

C->S: 請(qǐng)求一個(gè)受保護(hù)的頁面

S->C：返回附帶公鑰的證書

C：檢查證書是否授信，不授信則提示客戶端 C：產(chǎn)生一臨時(shí)的對(duì)稱密鑰，并用服務(wù)端的公鑰加密

C：用服務(wù)端的公鑰加密需要請(qǐng)求的地址和附加的參數(shù)

C->S:將加密過的密鑰和請(qǐng)求內(nèi)容發(fā)送給服務(wù)端

S：首先用私鑰解密獲得兩者交互的臨時(shí)對(duì)稱密鑰

S->C：將請(qǐng)求的內(nèi)容通過臨時(shí)對(duì)稱密鑰加密返回給客戶端

C->S：通過臨時(shí)對(duì)稱密鑰開始交互

S->C：通過臨時(shí)對(duì)稱密鑰加密并返回內(nèi)容

數(shù)字證書

數(shù)字證書稱為數(shù)字標(biāo)識(shí)（Digital Certificate，Digital ID）。它提供了一種在 Internet 上身份驗(yàn)證的方式，是用來標(biāo)志和證明網(wǎng)絡(luò)通信雙方身份的數(shù)字信息文件，與司機(jī)駕照或日常生活中的身份證相似。數(shù)字證書它是由一個(gè)由權(quán)威機(jī)構(gòu)即 CA機(jī)構(gòu)，又 稱為證書授權(quán)（Certificate Authority）中心發(fā)行的，人們可以在交往中用它來識(shí)別對(duì)方的身份。在網(wǎng)上進(jìn)行電子商務(wù)活動(dòng)時(shí)，交易雙方需要使用數(shù)字證書來表明自己的身份，并使用數(shù)字證書來進(jìn)行有關(guān)交易操作。通俗地講，數(shù)字證書就是個(gè)人或單位在 Internet上的身份證。

比較專業(yè)的數(shù)字證書定義是，數(shù) 字證書是一個(gè)經(jīng)證書授權(quán)中心數(shù)字簽名的包含公開密鑰擁有者信息以及公開密鑰的文件。最簡(jiǎn)單的證書包含一個(gè)公開密鑰、名稱以及證書授權(quán)中心的數(shù)字簽名。一般情況下證書中還包括密鑰的有效時(shí)間，發(fā)證機(jī)關(guān)（證書授權(quán)中心）的名稱，該證書的序列號(hào)等信息，證書的格式遵循相關(guān)國際標(biāo)準(zhǔn)。有了數(shù)字證書，我們?cè)诰W(wǎng)絡(luò)上就 可以暢通無阻。如圖(數(shù)字證書授權(quán)中心)是一個(gè)數(shù)字證書在網(wǎng)絡(luò)應(yīng)用中的原理圖。

圖：數(shù)字證書授權(quán)中心

為什么需要數(shù)字證書呢？Internet網(wǎng)電子商務(wù)系統(tǒng)技術(shù)使在網(wǎng)上購物的顧客能夠極其方便輕松地獲得商家和企業(yè)的信息，但同時(shí)也增加了對(duì)某些敏感或有價(jià)值的數(shù)據(jù)被濫用的風(fēng)險(xiǎn)。買方和賣方都必須對(duì)于在因特網(wǎng)上進(jìn)行的一切金融交易運(yùn)作都是真實(shí)可靠的，并且要使顧客、商家和企業(yè)等交易各方都具有絕對(duì)的信心，因而網(wǎng)絡(luò)電子商務(wù)系統(tǒng)必須保證具有十分可靠的安全保密技術(shù)，也就是說，必須保證網(wǎng)絡(luò)安全的四大要素，即信息傳輸?shù)谋Ｃ苄?、?shù)據(jù)交換的完整性、發(fā)送信息的不可否認(rèn)性、交易者身份的確定性。

下面就是在證書中所包含的元素的列表。

? ? 版本 ：它用來區(qū)別 X.509的各種連續(xù)的版本。默認(rèn)值是 1988版本。

序列號(hào) ：序列號(hào)是一個(gè)整數(shù)值，在發(fā)行的證書頒發(fā)機(jī)構(gòu)中是唯一的。序列號(hào)與證書有明確聯(lián)系，就像身份證號(hào)碼和公民日常登記有明確聯(lián)系一樣。

? 算法識(shí)別符 ：算法識(shí)別符識(shí)別證書頒發(fā)機(jī)構(gòu)用來簽署證書的算法。證書頒發(fā)機(jī)構(gòu)使用它的私鑰對(duì)每個(gè)證書進(jìn)行簽名。

? ? 發(fā)行者或證書頒發(fā)機(jī)構(gòu) ：證書頒發(fā)機(jī)構(gòu)是創(chuàng)建這個(gè)證書的機(jī)構(gòu)。

有效期 ：提供證書有效的起止日期，類似于信用卡的期限。

?

?

主體 ：證書對(duì)他的身份進(jìn)行驗(yàn)證。

公鑰信息 ：為證書識(shí)別的主體提供公鑰和算法識(shí)別符。? 簽名 ：證書簽名覆蓋了證書的所有其他字段。簽名是其他字段的哈希代碼，使用證書頒發(fā)機(jī)構(gòu)的私鑰進(jìn)行加密，保證整個(gè)證書中信息的完整性。如果有人使用了證 書頒發(fā)機(jī)構(gòu)的公鑰來解密這個(gè)哈希代碼，同時(shí)計(jì)算了證書的哈希代碼，而兩者并不相同，那么證書的某一部分就肯定被非法更改了。

圖：證書內(nèi)容

有了 數(shù)字證書以后，我們可以進(jìn)行發(fā)送安全的電子郵件，實(shí)現(xiàn)網(wǎng)上郵件的加密和簽名電子郵件，它還可以應(yīng)用于公眾網(wǎng)絡(luò)上的商務(wù)活動(dòng)和行政作業(yè)活動(dòng)，應(yīng)用范圍涉及需要身份認(rèn)證及數(shù)據(jù)安全的各個(gè)行業(yè)，如訪問安全站點(diǎn)、網(wǎng)上招標(biāo)投標(biāo)、網(wǎng)上簽約、網(wǎng)上訂購、安全網(wǎng)上公文傳送、網(wǎng)上辦公、網(wǎng)上繳費(fèi)、網(wǎng)上繳稅、網(wǎng)上購物等網(wǎng)上 的安全電子事務(wù)處理和安全電子交易活動(dòng)等。隨著電子商務(wù)和電子政務(wù)的不斷發(fā)展，數(shù)字證書的頒發(fā)機(jī)構(gòu) CA中心將作為一種基礎(chǔ)設(shè)施為電子商務(wù)的發(fā)展提供可靠的保障。

Appendix2

SSL uses a scheme of https to reference documents available under HTTP with SSL.The https has a IANA reserved number of 443.SSL supports the RC2 & RC4 with either 128 bits or 40 bits of secret key information, as well as DES, 3 key 3DES, and IDEA.Details of all are covered in Schneier.A.The threats

As long as they confine themselves to playing by the rules established by Netscape, lookers can do little harm.There's little a looker with minimal resources can do against the deployed crypto systems used in SSL.Hacking one or more of the hosts or key certification authorities would seem to be a better option.Insiders, especially those around the top of the key certification hierarchy, have the potential to do quite a bit of harm by creating false signatures on keys.Few of these attacks will occur in a vengeful manner;they require time and foresight to enact, and are probably the domain of the malicious employee.(This assumes that employees who become vengeful do so at about the time they leave a firm.)

A criminal organization could, depending on its resources, possibly target an employee at a key certification organization.However, a more useful option might be to buy a cheap PC, and have it attempt brute force RC4 keys.It is estimated that a pentium based PC should be able to crack a 40 bit RC4 key in a month or several months using brute force.The manipulations used on the master key may increase the cost of tha attack, but probably not by orders of magnitude.If a PC costs $1500, then breaking 12 keys a year leads to a cost that could be as low as $125 per stolen card number.While this seems like a high price, the credit card numbers are acquired in a nearly risk free manner of sniffing an ethernet.In addition, that time will drop with the introduction of faster hardware.B.Protections

SSL explicitly examines a number of attacks that can be made against it, including brute force, clear text cryptanalysis, replay, and man in the middle.It does seem to protect well against those forms of attack.SSL is designed to protect at the network layer.This means it is not designed to, and does not, protect you from host breakins.To protect against host breakins, a Tripwire-like package should be integrated with the HTTPd.Tripwire uses cryptographically strong hashes to ensure documents have not been changed from some reference version.The database is usually stored on a physically write protected media like a floppy(Kim).C.Weaknesses

SSL, being a low level protocol, does little to protect you once your host is compromised.Also, once a key in a certificate is compromised, it can remain compromised, as there is no mechanism in place for consulting the root of a CA to confirm the key you are using has not been revoked.The keys however do include expiration dates.Climbing to the root CA is not a commonplace step, but a mechanism should be available to do so, for high value transactions.Out of band key repudiation is also desirable.Today, trusted key certifiers are compiled into the Netscape binary.The use of RC4 is troublesome, albeit understandable.RC4 is a newly published cipher, and although it was designed by the very competent Ron Rivest, it has not been subjected to the same kind of intense professional scrutiny that DES and IDEA have undergone.The decision to use RC4-40 is driven by the fact that it gets automatic export approval from the State Department.There are also a number of areas in the design of SSL as it stands that could become exploitable problems.None suggest an immediate means of attack, but are things which could be modified for possible added surety.Handshaking protocol: The challenge data, sent in the CLIENT-HELLO message, could in some types of handshakes, be sent later, encrypted.The data used in generating the session keys could include more data not sent in the clear.The means of generating the master key should be better specified, probably with reference to RFC-1750.Record protocol: Bad MAC-data should not terminate a connection, it should cause a repeat-request message.There are few attacks that will get anything from having the same data resent, and closing the connection on a bad message opens avenues for denial of service attacks.Sequence numbers should be randomly initialized.There are quite a few non-obvious attacks on sequence numbers(in IP, and NFS);it can't hurt to start with a non-predictable number.There should be a way for one or both sides to demand renegotiation of keys.Perhaps this could be implemented as a security escape.This is not needed for HTTP connection security, since the connections are very short lived, but if SSL is used, as the authors suggest, for telnet or FTP, the sessions could last substantially longer.