⑴ set 協議描述
SET安全協議(Secure Electronic Transactions，簡稱 SET)
SET標准（http://www.setco.com） SET是為了在Internet上進行在線交易時保證信用卡支付的安全而設立的一個開放的規范。它是由Visa國際組織和萬事達組織共同制定的一個能保證通過開放網路(包括Internet)進行安全資金支付的技術標准。SET主要由三個文件組成,分別是SET業務描述、SET程序員指南和SET協議描述。SET1.0版已經公布並可應用於任何銀行支付服務。
由於設計合理，SET協議得到了IBM、HP、Microsoft、Netscape、VeriFone、GTE、VeriSign等許多大公司的支持，目前已獲得IETF標準的認可，成為B TO C業務事實上的工業標准。
安全電子交易是基於網際網路的銀行卡支付系統，是授權業務信息傳輸的安全標准，它採用RSA公開密鑰體系對通信雙方進行認證。利用DES、RC4或任何標准對稱加密方法進行信息的加密傳輸，並用HASH演算法來鑒別消息真偽，有無篡改。在SET體系中有一個關鍵的認證機構（CA），CA根據X.509標准發布和管理證書。
1. SET安全協議運行的目標
SET協議要達到的的目標主要有五個：
（1）保證信息在網際網路上安全傳輸，防止數據被黑客或被內部人員竊取。�
（2）保證電子商務參與者信息的相互隔離。客戶的資料加密或打包後通過商家到達銀行，但是商家不能看到客戶的帳戶和密碼信息。
（3）解決多方認證問題，不僅要對消費者的信用卡認證，而且要對在線商店的信譽程度認證，同時還有消費者、在線商店與銀行間的認證。
(4)保證了網上交易的實時性，使所有的支付過程都是在線的。
(5)效仿EDI貿易的形式，規范協議和消息格式，促使不同廠家開發的軟體具有兼容性和互操作功能，並且可以運行在不同的硬體和操作系統平台上。
2. SET安全協議涉及的范圍
SET協議規范所涉及的對象有：
(1)消費者，包括個人消費者和團體消費者，按照在線商店的要求填寫定貨單，通過由發卡銀行發行的信用卡進行付款。
(2)在線商店，提供商品或服務，具備相應電子貨幣使用的條件。
(3)收單銀行，通過支付網關處理消費者和在線商店之間的交易付款問題。
(4)電子貨幣（如智能卡、電子現金、電子錢包）發行公司，以及某些兼有電子貨幣發行的銀行。負責處理智能卡的審核和支付工作。
(5)認證中心（CA）。負責對交易對方的身份確認，對廠商的信譽度和消費者的支付手段進行認證。
3、SET的認證
在用戶身份認證方面，SET引入了證書（Certificates）和證書管理機構（Certificates Authorities）機制。
(a)證書
證書就是一份文檔，它記錄了用戶的公共密鑰和其他身份信息。在SET中，最主要的證書是持卡人證書和商家證書。
持卡人證書：它實際上是支付卡的一種電子化表示。它是由金融機構以數字簽名形式簽發的，不能隨意改變。持卡人證書並不包括帳號和終止日期信息，取而代之的是用單向哈希演算法根據帳號、截止日期生成的一個編碼，如果知道帳號、截止日期、密碼值即可導出這個碼值，反之不行。
商家證書：表示可接受何種卡來進行商業結算。它是由金融機構簽發的，不能被第三方改變。在SET環境中，一個商家至少應有一對證書。一個商家也可以有多對證書，表示它與多個銀行有合作關系，可以接受多種付款方法。
除了持卡人證書和商家證書以外，還有支付網關證書、銀行證書、發卡機構證書。
（b） 證書管理機構
CA是受一個或多個用戶信任，提供用戶身份驗證的第三方機構。證書一般包含擁有者的標識名稱和公鑰，並且由CA進行過數字簽名。
CA的功能主要有：接收注冊請求，處理、批准/拒絕請求，頒發證書。用戶向CA提交自己的公共密鑰何代表自己身份的信息（如身份證號碼或E-mail地址），CA驗證了用戶的有效身份之後，向用戶頒發一個經過CA私有密鑰簽名的證書。
（c）證書的樹形驗證結構
在兩方通信時，通過出示由某個CA簽發的證書來證明自己的身份，如果對簽發證書的CA本身不信任，則可驗證CA的身份，依次類推，一直到公認的權威CA處。就可確信證書的有效性。SET證書正是通過信任層次來逐級驗證的。
通過SET的認證機制，用戶不再需要驗證並信任每一個想要交換信息的用戶的公共密鑰，而只需要驗證並信任頒發證書的CA的公共密鑰就可以了。
4、SET標準的應用
自1996年始，34個國家的150多家金融機構制定了SET試行方案。從新加坡到舊金山的信用卡公司都開始建造SET交易網關，軟體廠家則著手開發支持SET的應用軟體。
⑵ 舉例說明set協議和ssl協議的區別
兩種都是應用於電子商務用的
網路
安全協議。都能保證交易數據的安全性、保密性和完整性。
SSL叫安全套接層協議，是國際上最早用的，已成工業標准，但它的基點是商家對客戶信息保密的承諾，因此有利於商家而不利於客戶。
SET叫安全電子交易協議，是為了在互聯網上進行在線交易時保證信用卡支付的安全而設立的一個開放的規范。因它的對象包括消費者、商家、發卡銀行、收單銀行、支付網關、認證中心，所以對消費者與商家同樣有利。它越來越得到眾人認同，將會成為未來電子商務的規范
近年來，IT業界與金融行業一起，推出不少更有效的安全交易標准。主要有：
(1) 安全超文本傳輸協議（S-HTTP）：依靠密鑰對的加密，保障Web站點間的交易信息傳輸的安全性。
(2) 安全套接層協議（SSL協議：Secure Socket Layer)是由網景（Netscape）公司推出的一種安全通信協議，是對計算機之間整個會話進行加密的協議，提供了加密、認證服務和報文完整性。它能 夠對信用卡和個人信息提供較強的保護。SSL被用於Netscape Communicator和Microsoft IE瀏覽器，用以完成需要的安全交易操作。在SSL中，採用了公開密鑰和私有密鑰兩種加密方法。
(3) 安全交易技術協議(STT：Secure Transaction Technology)：由Microsoft公司提出，STT將認證和解密在瀏覽器中分離開，用以提高安全控制能力。Microsoft將在 Internet Explorer中採用這一技術。
(4) 安全電子交易協議（SET：Secure Electronic Transaction）：SET協議是由VISA和MasterCard兩大信用卡公司於1997年5月聯合推出的規范。SET主要是為了解決用戶、商 家和銀行之間通過信用卡支付的交易而設計的，以保證支付信息的機密、支付過程的完整、商戶及持卡人的合法身份、以及可操作性。SET中的核心技術主要有公 開密匙加密、電子數字簽名、電子信封、電子安全證書等。
目前公布的SET正式文本涵蓋了信用卡在電子商務交易中的交易協定、信息保密、資料完整及數字認證、數字簽名等。這一標准被公認為全球網際網路的標准，其交易形態將成為未來「電子商務」的規范。
支付系統是電子商務的關鍵，但支持支付系統的關鍵技術的未來走向尚未確定。安全套接層（SSL）和安全電子交易（SET）是兩種重要的通信協議， 每一種都提供了通過Internet進行支付的手段。但是，兩者之中誰將領導未來呢？SET將立刻替換SSL嗎？SET會因其復雜性而消亡嗎？SSL真的 能完全滿足電子商務的需要嗎？我們可以從以下幾點對比作管中一窺：
SSL提供了兩台機器間的安全連接。支付系統經常通過在SSL連接上傳輸信用卡卡號的方式來構建，在線銀行和其他金融系統也常常構建在SSL之 上。雖然基於SSL的信用卡支付方式促進了電子商務的發展，但如果想要電子商務得以成功地廣泛開展的話，必須採用更先進的支付系統。SSL被廣泛應用的原 因在於它被大部分Web瀏覽器和Web伺服器所內置，比較容易被應用。
SET和SSL除了都採用RSA公鑰演算法以外，二者在其他技術方面沒有任何相似之處。而RSA在二者中也被用來實現不同的安全目標。
SET是一種基於消息流的協議，它主要由MasterCard和Visa以及其他一些業界主流廠商設計發布，用來保證公共網路上銀行卡支付交易的安全性。SET已經在國際上被大量實驗性地使用並經受了考驗，但大多數在Internet上購的消費者並沒有真正使用SET。
SET是一個非常復雜的協議，因為它非常詳細而准確地反映了卡交易各方之間存在的各種關系。SET還定義了加密信息的格式和完成一筆卡支付交易過 程中各方傳輸信息的規則。事實上，SET遠遠不止是一個技術方面的協議，它還說明了每一方所持有的數字證書的合法含義，希望得到數字證書以及響應信息的各 方應有的動作，與一筆交易緊密相關的責任分擔。
. SSL安全協議
SSL安全協議最初是由Netscape Communication公司設計開發的，又叫「安全套接層（Secure Sockets Layer）協議」，主要用於提高應用程序之間的數據的安全系數。SSL協議的整個概念可以被總結為：一個保證任何安裝了安全套接字的客戶和伺服器間事務 安全的協議，它涉及所有TC/IP應用程序。
SSL安全協議主要提供三方面的服務：
用戶和伺服器的合法性認證
認證用戶和伺服器的合法性，使得它們能夠確信數據將被發送到正確的客戶機和伺服器上。客戶機和伺服器都是有各自的識別號，這些識別號由公開密鑰進行編號，為了驗證用戶是否合法，安全套接層協議要求在握手交換數據進行數字認證，以此來確保用戶的合法性。
加密數據以隱藏被傳送的數據
安全套接層協議所採用的加密技術既有對稱密鑰技術，也有公開密鑰技術。在客戶機與伺服器進行數據交換之前，交換SSL初始握手信息，在SSL握手 情息中採用了各種加密技術對其加密，以保證其機密性和數據的完整性，並且用數字證書進行鑒別。這樣就可以防止非法用戶進行破譯。
護數據的完整性
安全套接層協議採用Hash函數和機密共享的方法來提供信息的完整性服務，建立客戶機與伺服器之間的安全通道，使所有經過安全套接層協議處理的業務在傳輸過程中能全部完整准確無誤地到達目的地。
⑶ 這是什麼加密方式
7種html加密方式介紹2009-11-26 12:35一：最簡單的加密解密
二：轉義字元""的妙用
三：使用Microsoft出品的腳本編碼器Script Encoder來進行編碼 （自創簡單解碼）
四：任意添加NUL空字元（十六進制00H） （自創）
五：無用內容混亂以及換行空格TAB大法
六：自寫解密函數法
七：錯誤的利用 （自創） 在做網頁時（其實是網頁木馬呵呵），最讓人煩惱的是自己辛辛苦苦寫出來的客戶端IE運行的JAVASCRIPT代碼常常被別人輕易的拷貝，實在讓自己的心裡有點不是滋味，要知道自己寫點東西也挺累的......^*^
但我們也應該清楚地認識到因為JAVASCRIPT代碼是在IE中解釋執行，要想絕對的保密是不可能的，我們要做的就是盡可能的增大拷貝者復制的難度，讓他知難而退（但願~!~），下面我結合自己這幾年來的實踐，及個人研究的心得，和大家一起來探討一下網頁中JAVASCRIPT代碼的加密解密技術。
以加密下面的JAVASCRIPT代碼為例：
以下是代碼片段：
<SCRIPT LANGUAGE="JavaScript">
alert("黑客防線");
</SCRIPT>一：最簡單的加密解密
大家對於JAVASCRIPT函數escape()和unescape()想必是比較了解啦（很多網頁加密在用它們），分別是編碼和解碼字元串，比如例子代碼用escape()函數加密後變為如下格式：
以下是代碼片段：
alert%28%22%u9ED1%u5BA2%u9632%u7EBF%22%29%3B
如何？還看的懂嗎？當然其中的ASCII字元"alert"並沒有被加密，如果願意我們可以寫點JAVASCRIPT代碼重新把它加密如下：
以下是代碼片段：
%61%6C%65%72%74%28%22%u9ED1%u5BA2%u9632%u7EBF%22%29%3B呵呵！如何？這次是完全都加密了！
當然，這樣加密後的代碼是不能直接運行的，幸好還有eval(codeString)可用，這個函數的作用就是檢查JavaScript代碼並執行，必選項 codeString 參數是包含有效 JavaScript 代碼的字元串值，加上上面的解碼unescape()，加密後的結果如下：
以下是代碼片段：
<SCRIPT LANGUAGE="JavaScript">
var code=unescape("%61%6C%65%72%74%28%22%u9ED1%u5BA2%u9632%u7EBF%22%29%3B");
eval(code)
</SCRIPT>
是不是很簡單？不要高興，解密也就同樣的簡單，解密代碼都擺給別人啦（unescape()）！呵呵
二：轉義字元""的妙用
大家可能對轉義字元""不太熟悉，但對於JavaScript提供了一些特殊字元如：n （換行）、 r （回車）、' （單引號 ）等應該是有所了解的吧？其實""後面還可以跟八進制或十六進制的數字，如字元"a"則可以表示為："141"或"x61"（注意是小寫字元"x"），至於雙位元組字元如漢字"黑"則僅能用十六進製表示為"u9ED1"（注意是小寫字元"u"），其中字元"u"表示是雙位元組字元，根據這個原理例子代碼則可以表示為：
八進制轉義字元串如下:
以下是代碼片段：
<SCRIPT LANGUAGE="JavaScript">
eval("")
</SCRIPT>十六進制轉義字元串如下:
以下是代碼片段：
<SCRIPT LANGUAGE="JavaScript">
eval("")
</SCRIPT>這次沒有了解碼函數，因為JavaScript執行時會自行轉換，同樣解碼也是很簡單如下：
以下是代碼片段：
<SCRIPT LANGUAGE="JavaScript">
alert("")
</SCRIPT>
就會彈出對話框告訴你解密後的結果！
三：使用Microsoft出品的腳本編碼器Script Encoder來進行編碼
工具的使用就不多介紹啦！我是直接使用JavaScript調用控制項Scripting.Encoder完成的編碼！代碼如下：
以下是代碼片段：
<SCRIPT LANGUAGE="JavaScript">
var Senc=new ActiveXObject("Scripting.Encoder");
var code='<SCRIPT LANGUAGE="JavaScript">rnalert("黑客防線");rn</SCRIPT>';
var Encode=Senc.EncodeScriptFile(".htm",code,0,"");
alert(Encode);
</SCRIPT>編碼後的結果如下：
以下是代碼片段：
<SCRIPT LANGUAGE="JScript.Encode">#@~^FgAAAA==@#@&ls DD`J黑客防線r#p@#@&FgMAAA==^#~@</SCRIPT>夠難看懂得吧？但相應的解密工具早已出來，而且連解密網頁都有！因為其解密網頁代碼過多，我就不多說拉！給大家介紹一下我獨創的解密代碼，如下：
以下是代碼片段：
<SCRIPT LANGUAGE="JScript.Encode">
function decode()
alert(decode.toString());
</SCRIPT>咋樣？夠簡單吧？它是原理是：編碼後的代碼運行前IE會先對其進行解碼，如果我們先把加密的代碼放入一個自定義函數如上面的decode()中，然後對自定義函數decode調用toString()方法，得到的將是解碼後的代碼！
如果你覺得這樣編碼得到的代碼LANGUAGE屬性是JScript.Encode，很容易讓人識破，那麼還有一個幾乎不為人知的window對象的方法execScript()，其原形為：
window.execScript( sExpression, sLanguage )
參數：
sExpression: 必選項。字元串(String)。要被執行的代碼。
sLanguage: 必選項。字元串(String)。指定執行的代碼的語言。默認值為 Microsoft JScript
使用時，前面的"window"可以省略不寫！
利用它我們可以很好的運行編碼後的JavaScript代碼，如下：
以下是代碼片段：
<SCRIPT LANGUAGE="JavaScript">
execScript("#@~^FgAAAA==@#@&ls DD`J黑客防線r#p@#@&FgMAAA==^#~@","JScript.Encode")
</SCRIPT>
你可以利用方法二對其中的""號內的字元串再進行編碼，使得"JScript.Encode"以及編碼特徵碼"#@~^"不出現，效果會更好！
四：任意添加NUL空字元（十六進制00H）
一次偶然的實驗，使我發現在HTML網頁中任意位置添加任意個數的"空字元"，IE照樣會正常顯示其中的內容，並正常執行其中的JavaScript 代碼，而添加的"空字元"我們在用一般的編輯器查看時，會顯示形如空格或黑塊，使得原碼很難看懂，如用記事本查看則"空字元"會變成"空格"，利用這個原理加密結果如下：（其中顯示的"空格"代表"空字元"）
以下是代碼片段：
<S C RI P T L ANG U A G E =" J a v a S c r i p t ">
a l er t (" 黑 客 防 線") ;
< / SC R I P T>
如何？是不是顯得亂七八糟的？如果不知道方法的人很難想到要去掉裡面的"空字元"（00H）的！
五：無用內容混亂以及換行空格TAB大法
在JAVASCRIPT代碼中我們可以加入大量的無用字元串或數字，以及無用代碼和注釋內容等等，使真正的有用代碼埋沒在其中，並把有用的代碼中能加入換行、空格、TAB的地方加入大量換行、空格、TAB，並可以把正常的字元串用""來進行換行，這樣就會使得代碼難以看懂！如我加密後的形式如下：
以下是代碼片段：
<SCRIPT LANGUAGE="JavaScript">
"xajgxsadffgds";1234567890
625623216;var $=0;alert//@$%%&*()(&(^%^
//cctv function//
(//hhsaasajx xc
/*
asjgdsgu*/
"黑客防線"//ashjgfgf
/*
@#%$^&%$96667r45fggbhytjty
*/
//window
)
;"#@$#%@#432hu";212351436
</SCRIPT>
至少如果我看到這樣的代碼是不會有心思去分析它的，你哪？
六：自寫解密函數法
這個方法和一、二差不多，只不過是自己寫個函數對代碼進行解密，很多VBS病毒使用這種方法對自身進行加密，來防止特徵碼掃描！下面是我寫的一個簡單的加密解密函數，
加密代碼如下（詳細參照文件"加密.htm"）：
以下是代碼片段：
<SCRIPT LANGUAGE="JavaScript">
function compile(code)
{
var c=String.fromCharCode(code.charCodeAt(0)+code.length);
for(var i=1;i<code.length;i++){
c+=String.fromCharCode(code.charCodeAt(i)+code.charCodeAt(i-1));
}
alert(escape(c));
}
compile('alert("黑客防線");')
</SCRIPT>運行得到加密結果為：o%CD%D1%D7%E6%9CJ%u9EF3%uFA73%uF1D4%u14F1%u7EE1Kd
相應的加密後解密的代碼如下：
以下是代碼片段：
<SCRIPT LANGUAGE="JavaScript">
function uncompile(code)
{
code=unescape(code);
var c=String.fromCharCode(code.charCodeAt(0)-code.length);
for(var i=1;i<code.length;i++){
c+=String.fromCharCode(code.charCodeAt(i)-c.charCodeAt(i-1));
}
return c;
}
eval(uncompile("o%CD%D1%D7%E6%9CJ%u9EF3%uFA73%uF1D4%u14F1%u7EE1Kd"));
</SCRIPT>
七：錯誤的利用
利用try{}catch(e){}結構對代碼進行測試解密，雖然這個想法很好（呵呵，誇誇自己），因為實用性不大，我僅給個例子
以下是代碼片段：
<SCRIPT LANGUAGE="JavaScript">
var a='alert("黑客防線");';
var c="";
for(var i=0;i<a.length;i++){
c+=String.fromCharCode(a.charCodeAt(i)^61);}
alert(c);//上面的是加密代碼，當然如果真正使用這個方法時，不會把加密寫上的
//現在變數c就是加密後的代碼
//下面的函數t()先假設初始密碼為０，解密執行，
//遇到錯誤則把密碼加１，然後接著解密執行，直到正確運行
以下是代碼片段：
var d=c; //保存加密後的代碼
var b=0; //假定初始密碼為0
t();
function t()catch(e){
c="";
for(var i=0;i<d.length;i++){
c+=String.fromCharCode(d.charCodeAt(i)^b);}
b+=1;
t();
//setTimeout("t()",0);
}
}
</SCRIPT>
⑷ 簡述SSL協議與SET協議的工作原理
SSL協議的工作流程： 伺服器認證階段：1）客戶端向伺服器發送一個開始信息「Hello」以便開始一個新的會話連接；2）伺服器根據客戶的信息確定是否需要生成新的主密鑰，如需要則伺服器在響應客戶的「Hello」信息時將包含生成主密鑰所需的信息；3）客戶根據收到的伺服器響應信息，產生一個主密鑰，並用伺服器的公開密鑰加密後傳給伺服器；4）伺服器恢復該主密鑰，並返回給客戶一個用主密鑰認證的信息，以此讓客戶認證伺服器。 set協議的交易流程： 用戶認證階段：在此之前，伺服器已經通過了客戶認證，這一階段主要完成對客戶的認證。經認證的伺服器發送一個提問給客戶，客戶則返回（數字）簽名後的提問和其公開密鑰，從而向伺服器提供認證SET交易過程中要對商家，客戶，支付網關等交易各方進行身份認證，因此它的交易過程相對復雜。 (1)客戶在網上商店看中商品後，和商家進行磋商，然後發出請求購買信息。 (2)商家要求客戶用電子錢包付款。 (3)電子錢包提示客戶輸入口令後與商家交換握手信息，確認商家和客戶兩端均合法。 (4)客戶的電子錢包形成一個包含訂購信息與支付指令的報文發送給商家。 (5)商家將含有客戶支付指令的信息發送給支付網關。 (6)支付網關在確認客戶信用卡信息之後，向商家發送一個授權響應的報文。 (7)商家向客戶的電子錢包發送一個確認信息。 (8)將款項從客戶帳號轉到商家帳號，然後向顧客送貨，交易結束。 從上面的交易流程可以看出，SET交易過程十分復雜性，在完成一次S ET協議交易過程中，需驗證電子證書9次，驗證數字簽名6次，傳遞證書7次，進行簽名5次，4次對稱加密和非對稱加密。通常完成一個SET協議交易過程大約要花費1.5－2分鍾甚至更長時間。由於各地網路設施良莠不齊，因此，完成一個SET協議的交易過程可能需要耗費更長的時間。
⑸ SET協議如何實現數字簽名
1995年 1o月.包括Mastercard.N etscape和IBM在內的聯盟開始進行安全
電子支付協議(SEPP)的開發.此前不久，Visa 和微軟組成的聯盟己經開始開發
另外一種不同的網路支付規范:安全交易技術(ST)。這樣便出現了一種不幸的
局面.兩大信用卡組織Mastercard和visa.分別支持獨立的網路支付解決方案.這
種局面持續了數月時間.在1996年1月，這些公司宜布它們將聯合開發統一的系
統.叫做安全電子交易(SET). 1996年2月末.它們發布了兩份文件，其中第一
份文件給出了SET協議的業務描述，而第二份文件給出了更多的技術細節。其後
經歷了一段公眾評論期。在此期間，感興趣的各方對該規范進行了討論.並指出
了其中的不當之處。此後，發表了修改後的文件—協議描述.，它定義了產品
SET協議。SET是一種基於消息流的協議，用來保證公共網路上銀行卡支付交易
的安全性。在Internet支付產業中，很多重要組織都聲明將支持SET. SET在國
際上己彼大t實驗性地使用井經受了考驗，但大多致在Intemet上采晌的消費者井
沒有賓正使用SET.
支付系統安全是電子商務的關鍵.SET支持了電子商務的特殊安全需要.如:
使用加密保證購物信息和支付信息的機密性:使用數字簽名確保支付信息的完整
性;使用持卡人證書.對使用信用卡的合法性進行認證;使用商家證書.對商家
進行認證;保證各方對有關事項的不可否認性。特別地.SET保證了不會籍待卡人的信用卡號泄落給商家.
下面 對 電 子商務的交易過程進行簡單的介紹。一個典型的墓於SET的電子商
務交易過程大體上可以用下面的一個簡單的例子來描述:
1. 在交易之前客戶應向其金觸機構(即發行機構或付欲銀行)申請銀行帳號.
商家 也 應 該向它的金融機構(收單銀行)申請銀行帳號，並且向認證中心注
冊得 到 所 漪要的證書。
2. 持卡人通過各種方式來瀏覽商品，如可以通過瀏覽器瀏覽商家電子商務服務
器的 We b頁面上的商品目錄;或瀏覽由商家提供的存儲在CD ROM上的商
品 目錄 : 查看印刷的商品目錄，井選擇要購買的商品。
3. 持卡人選擇一定的付欲方式，如選擇付欲卡的品牌。
4.持卡人(客戶)把完整的訂單以及付欲指令傳送給商家(付軟指令必須由合
法的 持 卡 人進行戴字簽名).
5. 商家向持卡人的金融機構請求付欲代理.
6. 商家向持卡人(客戶)發送定購確認.
7. 商家向持卡人(客戶)運送貨物或提供服務。
8. 商家從持卡人的金觸機構(付教銀行)取得貨教·
在整 個 交 易過程中SET參與了4,5 ,6 ,8 這幾個階段。在支付過程中SET
協議的參與者需要使用數字證書以證明自己的身份或交換會話密鑰。持卡者對自
己的數字證書和私鑰、信用卡號碼以及其他信息需耍進行加密存儲。它們與符合
SET協議的軟體一起組成了一個SET「電子錢包」。當持卡者在網上商店選中商品
並使用SET「電子錢包」付錢時，商家伺服器上的軟體發報文給持卡者的瀏覽器
要求SET「電子錢包」付錢，SET「電子錢包」則與商家伺服器交換「握手」消
息(包括得到商家的證書)，讓持卡者確認商家被授權可以接受付欲卡付欲。同時
商家也通過類似過程來臉證持卡人的證書以驗證其使用付欲卡的合法性。臉證合
法性之後才能進行支付信息的交換。在SET協議的消息流中所有教感信息都採用
密碼技術對其機密性、完整性等進行保護，同時對消息派進行認證。為能夠實現
這些安全功能，SET使用了致字簽名、數字信封、對偶簽名(也稱雙重簽名)等.SET安全電子交易系統中，商家，CCA.MCA.發行銀行，支付網關，支付卡品牌均有一對公開尹秘密密鑰交換密鑰和一對公開尹秘密簽名密鑰及相應的證書。持卡人有一對公開琳密簽名密鑰及相應的證書。除此以外，參與通信的各方均要求擁有加解密模塊、數字簽名了驗證模塊、具有密碼隨機性的隨機對稱密鑰生成器、能夠實現證書及其他安全今數的安全存貯的模塊等.它們一起組成了SET棋組。該模型中的部分消息可能是帶外完成的，例如商家注姍、持卡人注冊及頒發證書時的部分認證過程。SE T 安全 電子交易的整個過程大體可以分為以下幾個階段:持卡人(c)注
冊，商家(M)注冊，購物請求，付欲授權，付款結算.
一、持卡人注冊(Cardholder Registrafion)
持卡 人 C 在 實 兒電子交易之前必須先向其金勝機構(付欲銀行)注冊登記.
以便得到一個簽名證書.在這過程中.C為了保證消息的機密性.盆要使用CCA
的密鑰交換公鑰，它是從CCA的密鑰交換證書中得到(在初始響應中由CCA發
送)。注冊的大體步異如下:
1. c向CCA發送初始請求;
2- CCA接收初始請求;
3- CCA生成響應，井對響應進行致字簽名:
4- CCA把晌應連同證書一起發送給C;
5- C接收初始響應，井驗證CCA的證書;
6- C臉證CCA對響應的數字簽名:
7- C拍入帳號:
8- C生成注冊表請求:
9- c隨機生成對稱密鑰K二用K.對注冊表請求消息加密，K.與帳號一起用CCA
的密 鑰 交 換公鑰加密:
10- C發送加密後的注冊表請求給CCA;
It- CCA用密祖交換私鑰解密K.和帳號，用K.解密加密的注冊表請求;
12- CC^選擇合適的注冊表.井對其進行數字簽名;
13- CCA發送注冊表及CCA的證書給C-.
14- C接收注冊表並臉證CCA的證書:
15- C臉證CCA對注冊表的效字簽名;
16- C產生一公用秘密密鑰對和一個秘密的用於注冊帳號隨機數R
17- C墳寫注冊表井生成注冊表請求:
18- C生成由請求、c的公開鑰和新生成的對稱密鑰K:組成的消息，並簽名;
19- C將此消息用密鑰丸加密，吮、R.與帳號一起用CCA的密鑰交換公鑰加密:
20- C發送加密後的證書請求消息(包括加密的帳號和R,等)給CCA
21. CC人用密鑰交換私鑰解密K2、隨機數和帳號.用K,解密加密後的證書請求:
22- CCA驗證C的數字簽名:
23- CCA用帳戶信息和注冊表信息對C進行必要的臉證(SET中沒有具體規定):
24·根據驗證結果CCA生成隨機數凡，將凡、R,, C的帳號、有效期等信息的
散列 值 包 含在證書中，並簽名:
25- CCA生成證書應答(包含有加密的凡)並簽名:
26- CCA將證書應答用K:加密後發送給C;
27- C驗證CCA的證書並用K2解密消息:
28- C驗證CCA對證書的數字簽名後保留證書以及CC^產生的秘密隨機數R2
散列 函 數 作用於任愈長度的消息產生一個具有固定長度、在統計意義上唯一
的散列值。SET在實現數據完整性的時候，頻繁地使用散列函數。散列函數自身
井不能提供完整性，通常要把它和密鑰或者跟其他的演算法結合在一起。例如，它
和數字簽名結合在一起、在通信雙方具有共享密鑰時跟分組密碼結合在一起或使
用帶密鑰的散列函數等。散列函數一般僅要求具有以下性質:故列函致的演算法是
公開的:散列函數是一個單向函數;對於特定的散列函數尋找其碰撞消息對在計
算上是不可行的.SET中默認使用的散列函數是SHA. SHA演算法是NIST NSA設計的與DSS( Digitalsig natuers tandard)一起使用的一個敞列函數，它產生160bits
的散列值。與其 他 散 列演算法類似，首先將消息填充為512bits的整數倍:先添加一個比特
1,然後填充足夠多的零使其長度為512bits的整數倍減去64bits，最後的64bits
用於表示消息填充前的長度。
將 算 法 中的五個32bits的變數初始化: A= 0x67452301
B=Oxefcdab89。C=Ox98badcfe，D=0x10325476，E=Oxc3d2e1fO .
然後開始演算法主循環，每次處理512 bits的消息。因此，主循環的次數是消息所
包含的512bits分組的數目。
⑹ SET安全協議的密鑰體制其重點在於
1 A
2 B
3 c
4 c
6 A
7 A
8 D
9 C
10 B
11 D
12 B
⑺ 如何基於set協議實現電子商務交易安全
保證電子商務安全，對敏感信息和個人信息提供機密性保證、認證交易雙方的合法身份、保證數據的完整性和交易的不可否認性等，已經成為制約電子商務發展的瓶頸。基於SET協議的電子商務交易安全解決方案
1、加密方案：
當前電子商務中密碼應用發展要求提出新的加密方案。組合加密方案就是指在符合SET
協議標準的系統中，採用多種經過嚴格理論證明的，實踐表明是安全有效的成熟的演算法，而不局限於某種特定的演算法，按某種組合方式來進行加解密處理的加解密方案。
組合加密方案可以採用兩種組合方式：疊套加密方案和協商加密方案。
2、疊套加密方案：
本方案對明文信息採用二層加密，即自主加密和SET 加密，提高了系統的安全性。在擴展性方面，本方案有非常好的擴展性，可適應各種不同的自動加密演算法，
同時，可以反復套疊，以滿足各種不同加密強度的要求。
3、協商加密方案：
如果每個參與者都支持多證書和多數字簽名，可以採用協商加密方案。假設發起人A支持私鑰加密演算法DES、IDEA，公開密鑰演算法RSA和ElGamal，單向哈希演算法有MD5、SHA-
1;B是信息的接收者，它只支持DES、RSA 和SHA- 1 三種演算法。A、B的數字認證中心所支持的演算法與A一致。A通過演算法協商過程與B確定使用DES，SHA-
1 和RSA 演算法。
⑻ set協議是什麼
SET協議是指為了實現更加完善的即時電子支付應運而生的。SET協議(Secure Electronic Transaction)，被稱之為安全電子交易協議，是由Master Card和Visa聯合Netscape，Microsoft等公司，於1997年6月1日推出的一種新的電子支付模型。
SET協議是B2C上基於信用卡支付模式而設計的，它保證了開放網路上使用信用卡進行在線購物的安全。SET主要是為了解決用戶，商家，銀行之間通過信用卡的交易而設計的，它具有的保證交易數據的完整性，交易的不可抵賴性等種種優點，因此它成為目前公認的信用卡網上交易的國際標准。
主要目標：
1. 防止數據被非法用戶竊取，保證信息在互聯網上安全傳輸。
2. SET 中使用了一種雙簽名技術保證電子商務參與者信息的相互隔離。客戶的資料加密後通過商家到達銀行，但是商家不能看到客戶的帳戶和密碼信息。
3. 解決多方認證問題。不僅對客戶的信用卡認證，而且要對在線商家認證，實現客戶、商家和銀行間的相互認證。
4. 保證網上交易的實時性，使所有的支付過程都是在線的。
5. 提供一個開放式的標准，規范協議和消息格式，促使不同廠家開發的軟體具有兼容性和互操作功能。可在不同的軟硬體平台上執行並被全球廣泛接受。
⑼ 目前常用的加密解密演算法有哪些
加密演算法
加密技術是對信息進行編碼和解碼的技術，編碼是把原來可讀信息（又稱明文）譯成代碼形式（又稱密文），其逆過程就是解碼（解密）。加密技術的要點是加密演算法，加密演算法可以分為對稱加密、不對稱加密和不可逆加密三類演算法。
對稱加密演算法 對稱加密演算法是應用較早的加密演算法，技術成熟。在對稱加密演算法中，數據發信方將明文（原始數據）和加密密鑰一起經過特殊加密演算法處理後，使其變成復雜的加密密文發送出去。收信方收到密文後，若想解讀原文，則需要使用加密用過的密鑰及相同演算法的逆演算法對密文進行解密，才能使其恢復成可讀明文。在對稱加密演算法中，使用的密鑰只有一個，發收信雙方都使用這個密鑰對數據進行加密和解密，這就要求解密方事先必須知道加密密鑰。對稱加密演算法的特點是演算法公開、計算量小、加密速度快、加密效率高。不足之處是，交易雙方都使用同樣鑰匙，安全性得不到保證。此外，每對用戶每次使用對稱加密演算法時，都需要使用其他人不知道的惟一鑰匙，這會使得發收信雙方所擁有的鑰匙數量成幾何級數增長，密鑰管理成為用戶的負擔。對稱加密演算法在分布式網路系統上使用較為困難，主要是因為密鑰管理困難，使用成本較高。在計算機專網系統中廣泛使用的對稱加密演算法有DES和IDEA等。美國國家標准局倡導的AES即將作為新標准取代DES。
不對稱加密演算法不對稱加密演算法使用兩把完全不同但又是完全匹配的一對鑰匙—公鑰和私鑰。在使用不對稱加密演算法加密文件時，只有使用匹配的一對公鑰和私鑰，才能完成對明文的加密和解密過程。加密明文時採用公鑰加密，解密密文時使用私鑰才能完成，而且發信方（加密者）知道收信方的公鑰，只有收信方（解密者）才是唯一知道自己私鑰的人。不對稱加密演算法的基本原理是，如果發信方想發送只有收信方才能解讀的加密信息，發信方必須首先知道收信方的公鑰，然後利用收信方的公鑰來加密原文；收信方收到加密密文後，使用自己的私鑰才能解密密文。顯然，採用不對稱加密演算法，收發信雙方在通信之前，收信方必須將自己早已隨機生成的公鑰送給發信方，而自己保留私鑰。由於不對稱演算法擁有兩個密鑰，因而特別適用於分布式系統中的數據加密。廣泛應用的不對稱加密演算法有RSA演算法和美國國家標准局提出的DSA。以不對稱加密演算法為基礎的加密技術應用非常廣泛。
不可逆加密演算法 不可逆加密演算法的特徵是加密過程中不需要使用密鑰，輸入明文後由系統直接經過加密演算法處理成密文，這種加密後的數據是無法被解密的，只有重新輸入明文，並再次經過同樣不可逆的加密演算法處理，得到相同的加密密文並被系統重新識別後，才能真正解密。顯然，在這類加密過程中，加密是自己，解密還得是自己，而所謂解密，實際上就是重新加一次密，所應用的「密碼」也就是輸入的明文。不可逆加密演算法不存在密鑰保管和分發問題，非常適合在分布式網路系統上使用，但因加密計算復雜，工作量相當繁重，通常只在數據量有限的情形下使用，如廣泛應用在計算機系統中的口令加密，利用的就是不可逆加密演算法。近年來，隨著計算機系統性能的不斷提高，不可逆加密的應用領域正在逐漸增大。在計算機網路中應用較多不可逆加密演算法的有RSA公司發明的MD5演算法和由美國國家標准局建議的不可逆加密標准SHS(Secure Hash Standard:安全雜亂信息標准)等。
加密技術
加密演算法是加密技術的基礎，任何一種成熟的加密技術都是建立多種加密演算法組合，或者加密演算法和其他應用軟體有機結合的基礎之上的。下面我們介紹幾種在計算機網路應用領域廣泛應用的加密技術。
非否認（Non-repudiation）技術 該技術的核心是不對稱加密演算法的公鑰技術，通過產生一個與用戶認證數據有關的數字簽名來完成。當用戶執行某一交易時，這種簽名能夠保證用戶今後無法否認該交易發生的事實。由於非否認技術的操作過程簡單，而且直接包含在用戶的某類正常的電子交易中，因而成為當前用戶進行電子商務、取得商務信任的重要保證。
PGP（Pretty Good Privacy）技術 PGP技術是一個基於不對稱加密演算法RSA公鑰體系的郵件加密技術，也是一種操作簡單、使用方便、普及程度較高的加密軟體。PGP技術不但可以對電子郵件加密，防止非授權者閱讀信件；還能對電子郵件附加數字簽名，使收信人能明確了解發信人的真實身份；也可以在不需要通過任何保密渠道傳遞密鑰的情況下，使人們安全地進行保密通信。PGP技術創造性地把RSA不對稱加密演算法的方便性和傳統加密體系結合起來，在數字簽名和密鑰認證管理機制方面採用了無縫結合的巧妙設計，使其幾乎成為最為流行的公鑰加密軟體包。
數字簽名（Digital Signature）技術 數字簽名技術是不對稱加密演算法的典型應用。數字簽名的應用過程是，數據源發送方使用自己的私鑰對數據校驗和或其他與數據內容有關的變數進行加密處理，完成對數據的合法「簽名」，數據接收方則利用對方的公鑰來解讀收到的「數字簽名」，並將解讀結果用於對數據完整性的檢驗，以確認簽名的合法性。數字簽名技術是在網路系統虛擬環境中確認身份的重要技術，完全可以代替現實過程中的「親筆簽字」，在技術和法律上有保證。在公鑰與私鑰管理方面，數字簽名應用與加密郵件PGP技術正好相反。在數字簽名應用中，發送者的公鑰可以很方便地得到，但他的私鑰則需要嚴格保密。
PKI（Public Key Infrastructure）技術 PKI技術是一種以不對稱加密技術為核心、可以為網路提供安全服務的公鑰基礎設施。PKI技術最初主要應用在Internet環境中，為復雜的互聯網系統提供統一的身份認證、數據加密和完整性保障機制。由於PKI技術在網路安全領域所表現出的巨大優勢，因而受到銀行、證券、政府等核心應用系統的青睞。PKI技術既是信息安全技術的核心，也是電子商務的關鍵和基礎技術。由於通過網路進行的電子商務、電子政務等活動缺少物理接觸，因而使得利用電子方式驗證信任關系變得至關重要，PKI技術恰好能夠有效解決電子商務應用中的機密性、真實性、完整性、不可否認性和存取控制等安全問題。一個實用的PKI體系還必須充分考慮互操作性和可擴展性。PKI體系所包含的認證中心（CA）、注冊中心（RA）、策略管理、密鑰與證書管理、密鑰備份與恢復、撤銷系統等功能模塊應該有機地結合在一起。
加密的未來趨勢
盡管雙鑰密碼體制比單鑰密碼體制更為可靠，但由於計算過於復雜，雙鑰密碼體制在進行大信息量通信時，加密速率僅為單鑰體制的1/100，甚至是 1/1000。正是由於不同體制的加密演算法各有所長，所以在今後相當長的一段時期內，各類加密體制將會共同發展。而在由IBM等公司於1996年聯合推出的用於電子商務的協議標准SET（Secure Electronic Transaction）中和1992年由多國聯合開發的PGP技術中，均採用了包含單鑰密碼、雙鑰密碼、單向雜湊演算法和隨機數生成演算法在內的混合密碼系統的動向來看，這似乎從一個側面展示了今後密碼技術應用的未來。
在單鑰密碼領域，一次一密被認為是最為可靠的機制，但是由於流密碼體制中的密鑰流生成器在演算法上未能突破有限循環，故一直未被廣泛應用。如果找到一個在演算法上接近無限循環的密鑰流生成器，該體制將會有一個質的飛躍。近年來，混沌學理論的研究給在這一方向產生突破帶來了曙光。此外，充滿生氣的量子密碼被認為是一個潛在的發展方向，因為它是基於光學和量子力學理論的。該理論對於在光纖通信中加強信息安全、對付擁有量子計算能力的破譯無疑是一種理想的解決方法。
由於電子商務等民用系統的應用需求，認證加密演算法也將有較大發展。此外，在傳統密碼體制中，還將會產生類似於IDEA這樣的新成員，新成員的一個主要特徵就是在演算法上有創新和突破，而不僅僅是對傳統演算法進行修正或改進。密碼學是一個正在不斷發展的年輕學科，任何未被認識的加/解密機制都有可能在其中佔有一席之地。
目前，對信息系統或電子郵件的安全問題，還沒有一個非常有效的解決方案，其主要原因是由於互聯網固有的異構性，沒有一個單一的信任機構可以滿足互聯網全程異構性的所有需要，也沒有一個單一的協議能夠適用於互聯網全程異構性的所有情況。解決的辦法只有依靠軟體代理了，即採用軟體代理來自動管理用戶所持有的證書（即用戶所屬的信任結構）以及用戶所有的行為。每當用戶要發送一則消息或一封電子郵件時，代理就會自動與對方的代理協商，找出一個共同信任的機構或一個通用協議來進行通信。在互聯網環境中，下一代的安全信息系統會自動為用戶發送加密郵件，同樣當用戶要向某人發送電子郵件時，用戶的本地代理首先將與對方的代理交互，協商一個適合雙方的認證機構。當然，電子郵件也需要不同的技術支持，因為電子郵件不是端到端的通信，而是通過多個中間機構把電子郵件分程傳遞到各自的通信機器上，最後到達目的地。