Acrobat Distiller, Job 3

Size: px

Start display at page:

Download "Acrobat Distiller, Job 3"

押酌吕
7 years ago
Views:

1 逢甲大學資訊工程學系專題電子商務金融系統 The Financial System for Electronic Commerce 指導教授 : 李維斌博士 lwb@iecs.fcu.edu.tw 逢甲大學資訊工程學系學生 : 曾政國 cktw@taiwan.com 逢甲大學資訊工程學系中華民國九十年七月

2 摘要目前電子商務的安全交易機制多以 Visa 和 MasterCard 兩大發卡組織推廣的 SET (Secure Electronic Transaction) 機制和 Netscape 所提出的 SSL (Secure Socket Layer) 協定為主雖然 SET 提供高安全性, 可是卻因低便利性高成本而導致市場接受度不高, 而具備高便利性低成本安全性的 SSL, 在整個系統架構上卻不如 SET 嚴謹本文取 SET 及 SSL 的優點, 且改善兩系統的缺點, 進而建置一電子商務金融系統 (FSEC), 以做為 SET 和 SSL 的平衡點致謝首先得感謝我的指導教授李維斌博士, 才得以使這篇論文順利完成在當中的學習過程, 老師不斷地大力栽培, 使我能踏入資訊安全的領域, 在此非常感謝李老師的指導此外, 也謝謝英特連公司程經理鏈州先生及在 Citerus 工作的 Tobias Hill 技術指導與鼓勵

3 目錄第一章前言第二章 SET 與 SSL 線上購物運作過程 2-1 SET 線上購物運作過程 2-2 SSL 線上購物運作過程 2-3 SET 與 SSL 網路購物的相異處第三章相關理論與技術 3-1 電子憑證 (Certification) 3-2 數位簽章 (Digital Signature) DSA 3-3 JAVA Security Certification Java Signed Applet 3-4 自我簽署 JDK 3-5 FEDI 第四章電子商務金融系統 (FSEC) 雛型 4-1 FSEC 之準備 Payment Gateway 所扮演的角色 Web Based 系統之方法電子商務金融系統 (FSEC) 名詞定義 4-2 FSEC 交易 / 授權流程第五章討論 5-1 安全分析消費者的保障商家的保障發卡銀行與收款銀行的保障 5-2 SET SSL 與 FSEC 之比較 5-3 電子商務金融系統 FSEC 的特色第六章結論與未來展望第七章參考資料

4 第一章前言隨著網路發達, 網際網路已為我們生活帶來許多便利, 傳統的商業交易方式, 也延伸至網際網路成為電子商務然而電子商務最重要的就是便利性及安全性, 要如何在這兩者找到平衡點, 是大家一直努力的方向目前電子商務的安全交易機制多以 Visa 和 MasterCard 兩大發卡組織推廣的 SET (Secure Electronic Transaction) [2 6 10] 機制與 Netscape 所提出的 SSL (Secure Socket Layer) [1 3 18] 協定為主要交易方式, 而兩者各有其優缺點 SET 的基本構想是將交易中的金流與物流資訊徹底分開, 其安全核心技術有三, 分別是達成資料私密的加解密技術 ( Encryption / Decryption ) 維護資料完整的數位簽章 (Digital Signature) 及電子認證機制 (Certificate), 利用此三項安全核心來保障持卡人與網路商店在網路交易進行中雙方的權利 [21] 也由於需保障其交易過程中的安全性, 所以在 SET 電子商務機制中, 持卡人網路商店銀行都必須取得認證中心 (Certificate Authority, 簡稱 CA) 認證此外, 構成 SET 軟體規格的四個要素為持卡人的錢包軟體特約商店軟體支付閘門伺服器 (Payment Gateway Server) 軟體認證授權軟體 [13] 雖然 SET 三項安全核心為電子商務提供高安全性, 然而卻因各環節皆必須取得 CA 認證以及引入 SET 軟體規格的四個要素所產生的高複雜性高成本與低便利性等因素, 導致於 SET 的推廣不易而 SSL 則藉由通路的加密, 提供完整的隱私保護, 因為資料可經過公開的通路安全的傳送, 因此當持卡人與可信賴的網路商店往來時,SSL 可提供充分的安全性在 SSL 電子商務系統中, 是由 CA 去做網路商店認證, 使網路商店成為可信賴的商店 [1 13] 由於 SSL 成本低於 SET 且對持卡人而言不需安裝電子錢包等的考量, 造成目前 SSL 在全球使用率上高於 SET 然而在 SSL 交易過程中, 持卡人是透過網路商店進行信用卡授權交易, 因此網路商店將擁有持卡人的個人資料及信用卡資料, 一旦駭客入侵該網路商店竊取持卡人資料, 將造成重大損失這樣的事情正不斷地發生, 不少知名網站, 雖稱線上交易機制安全絕對無慮, 卻仍遭駭客入侵, 竊走用戶的資料, 如 : 唱片公司 Columbia House 網站旅遊網站 Travelocity 和全球最大線上零售網站亞馬遜旗下網站 Bibiofind 等因此儘管業者不斷強調線上交易的高度安全性, 但以一般使用 SSL 做為線上交易的機制, 其後端的安全性仍對網路商店及持卡人構成嚴重威脅, 因為 SSL 只關注在網路上傳輸時的安全性此外, 我們也無法要求所有網路商店花大成本來保護自己的網站基於上述原因, 在本文中, 我們將提出一電子商務金融系統 (FSEC) 達到以下目標 : 1 不讓商家取得持卡人信用卡資料 2 降低網路商店建置成本 3 消費者身分的認證 4 利用現有機制為基礎, 以提高可行性及降低成本 5 持卡人不需安裝電子錢包軟體

5 FSEC 是以 SSL 為基礎, 改善 SET 及 SSL 兩系統的缺點, 保留其優點, 再配合銀行網路所設計的電子商務金融系統本文的組織架構如下 : 在第二章, 我們將簡單地介紹 SET 與 SSL 線上購物的運作過程第三章將針對 FSEC 所需的準備做描述第四章則介紹 FSEC 的線上購物運作過程第五章將討論 SET SSL 與 FSEC 的比較和 FSEC 的特色第六章則是結論與對未來的展望第二章 SET 與 SSL 線上購物運作過程 2-1 SET 線上購物運作過程 SET 是一種應用於網際網路上, 以信用卡為基礎的電子系統交易機制, 用來保護開放網路上持卡交易的安全性以下將就持卡人於網際網路上經由 SET 做購物付款之流程做ㄧ概括描述 [13] 持卡人透過 Browser 瀏覽電子銀行的網頁, 當選定自行轉帳或繳款服務時, 由網頁服務 CGI 程式呼叫 SET POS 安全付款機制其交易處理過程如下 : 1 啟動電子錢包 2 電子錢包可讓持卡人選擇要使用哪一張金融卡電子錢包遵循 SET Protocol 將交易需求加密成 SET 訊息, 送往 SET POS Server 其中, 金融卡資料放在唯有 SET PG Server 可解開的加密封包, 其他轉帳指示資料放在唯有 SET POS Server 可解開的加密封包, 加上雙簽章 (Dual Signature) 的安全機制可確保這些重要的交易資料不被竄改另外,SET 訊息交換時, 以電子證書認證機制可驗正所有交易對象的合法身份 3 SET POS Server 遵循 SET Protocol 解出資料並作交易驗證後, 將交易需求加密成 SET 訊息, 送往 SET PG Server 4 SET PG Server 遵循 SET Protocol 解出資料並作交易驗證後, 將交易需求轉換成 ATM 所需的資料格式, 透過 SM 傳輸通道將交易需求送往 TM 5 TM 根據各銀行的需求, 與銀行主機連線溝通, 並作交易記錄 (Transaction Logging) 然後透過 SM 傳輸通道將交易回應送往 SET PG Server 6 SET PG Server 將交易回應轉換成 SET 訊息格式, 遵循 SET Protocol 將交易回應資料加密成 SET 訊息, 送回 SET POS Server 其中, 回給持卡人的帳戶餘額資料放在唯有電子錢包可解開的加密封包 7 SET POS Server 遵循 SET Protocol 解出資料並作交易驗證後, 一方面透過 SET POS API 定義的方式通知電子銀行的網頁服務系統, 一方面將交易回應資料加密成 SET 訊息, 送回電子錢包 8 持卡人在電子錢包上可看到交易完成後的帳戶餘額資料交易需求由

6 電子錢包送達 SET POS Server 後, 交易就算確立, 即使電子錢包在等待回應時離線, 交易仍會繼續進行, 持卡人隨時可用電子錢包查詢先前某筆交易的處理狀況 2-2 SSL 線上購物運作過程 SSL 本身是定位在 TCP/IP 通訊協定與應用程式間的一個安全通訊加密協定, 以下是一般使用 SSL 做網路購物時, 持卡人購物付款的概括描述 [19] 1 持卡人 (card holder) 在網路商店網頁選擇商品並填寫購買數量 2 填寫收貨人資料 ( 收貨人姓名連絡方式寄送地址等 ) 授權資料 ( 持卡人姓名信用卡卡別卡號有效日期到期日期 ) 使用 SSL 方式傳送資料至網路商店 3 網路商店收到持卡人之交易資料, 留下收貨人資料, 並幫持卡人取得授權, 將授權資料加密, 將授權資料使用 SSL 方式 ( 持卡人姓名信用卡卡別卡號有效日期到期日期交易金額 ) 傳給 Payment Gateway 4 Payment Gateway 將收到之授權資料, 轉換成 ISO8583 格式 ( 目前信用卡格式 ), 傳至收款銀行主機 5 收款銀行主機將授權資料透過金資中心傳至付款銀行進行授權請求 (ISO8583) 6 付款銀行透過金資中心傳送授權回應 (ISO8583) 至收款銀行主機 7 收款銀行主機將授權回應 (ISO8583) 傳送給 Payment Gateway 8 Payment Gateway 將授權回應 (ISO8583) 轉換成 SSL 交易格式, 並使用 SSL 方式傳給網路商店 9 網路商店收到授權回應資料, 取得授權交易成功, 並通知持卡人 10 送貨 11 網路商店將於送貨後第七日向信用卡中心請款 12 發票寄送 2-3 SET 與 SSL 網路購物的相異處我們從前面已經了解 SET 和 SSL 的網路購物流程, 也從前言知道兩者的安全性與便利性對市場的影響, 綜合以上結果, 將 SSL 與 SET 網路購物的比較, 整理成下面的表 ( 一 ) 表 ( 一 ) SSL 與 SET 網路購物的相異點交易模式 SSL SET 優點 1. 消費者使用方便 1. 身分確認性 2. 交易安全性 3. 資料完整性 4. 交易不可否認性

7 缺點 1. 每次消費需再填一次卡號 2. 風險負擔 3. 駭客入侵 1. 需要銀行申請網路信用卡及線上取得憑證的動作與時間 4. 信用卡卡號冒刷及外漏之風險安全性低高風險性責任歸屬商家及消費者 SET 相關銀行組織第三章相關理論與技術 3-1 電子憑證 (Certification) 電子憑證在電子商務中是很重要的一環, 透過電子憑證可以在網際網路中證實自己的身分, 進而獲得權限授權, 或藉由對方的電子憑證取得對方的公開金鑰在此系統, 除了商家必須取得電子憑證以證明自己的身份外,Java Signed Applet 更需取得電子憑證, 以證明其來源, 也才能存取使用者端的檔案資料而現在電子憑證的標準為 X.509 第三版, 其中規範了電子憑證的規格及相關的架構與演算法等 3-2 數位簽章 (Digital Signature) 數位簽章提供身份認證與資料完整保全兩種安全性服務一個成功認證的簽章除了確保訊息未遭他人篡改外, 更可以確認發訊者的身份不過, 簽章並不保證資料的機密性, 因為簽章是伴隨文字訊息一起傳送的, 任何攔下此訊息的人都可以很容易地閱讀訊息而簽章的功能定位在散播資訊, 杜絕偽造 DSA DSA 是由美國 NIST(National Institute Standards and Technology) 於 1991 年八月提出的數位簽章演算法, 之後便成為美國 FIPS(Federal Information Processing Standard) 標準之一 (FIPS 186), 因此也稱 DSA 為 DSS(Digital Signature Standard), 成為第一個被政府認可的數位簽章架構其原理概述如下.. 系統參數.. p 長度介於 512 到 1024 位元間的質數, 長度也同時是 64 的倍數 q (p-1) 的質因數, 長度為 160 位元 g g=h (p-1)/q,h 為整數, 且 1<h<(p-1), 滿足 g>1 條件

8 私密金鑰 x..x 為一隨機整數, 且 0<x<q 公開金鑰 y..y=g x mod p 簽名 (r,s)..r=(gk mod p)mod q,s=[k-1(h(m)+xr)]mod q k 為一隨機整數, 且 0<k<q, 每次簽名 k 皆不同驗證.. 確認收到的 r 是等於 [(g u1 y u2 )mod p]mod q, 其中.. u1=[h(m )*(s )-1]mod q,u2=r (s )-1mod q DSS 所用的雜湊函數 H() 是 SHA-1(Secure Hash Algorithm), 其雜湊值長度為 160 位元 3-3 JAVA Security Java 的安全是仰賴 Sandbox 的設計, 所謂 Sandbox 就是一個可以讓 Java 程式在其中執行運作的環境除此之外,Sandbox 也讓 Java 程式無法對外部環境造成破壞, 危害系統的安全當 applet 在瀏覽器的 Java 虛擬平台 (VM..Virtual Machine) 裡執行時, 限制更加嚴謹舉凡網路連線檔案存取到記憶體的使用等等都有所限制, 由於 Java 的能力受到 Sandbox 的限制, 因此 Sun 公司便設計新版的 Java, 讓經過簽署的 Java 程式可以突破部份限制, 取得對 Sandbox 外部資源存取的權限也因此 Java applelt 必須先經過簽署之後, 才可以取得對網路連線及檔案系統存取的權限而在 Java2 中,Sun 公司又更詳細地控制 Java 程式碼對系統權限的限制與取得, 這新的機制可以讓權限的控制限制在對某一網路主機或某 URL 連線或某一檔案目錄的讀取, 並同樣可以讓單台主機設定個別的 Java 權限機制, 以及指定權限是否需簽署過的 applet 才能執行 Certification Java2 支援到 X.509 v3 格式可以是 DER 或 BASE64, 電子簽章的演算法則支援 RSA 與 DSA Java Signed Applet 由於安全性的問題,applet 的執行被限制在 sandbox 內, 因此它有以下幾點限制 1 applet 是不可存取記憶體上任意位址, 這與瀏覽器的 SecurityManager 所作的其他限制不同, 此限制來自 Java 語言本身, 以及位元組檢驗程式 2 applet 不能以任何方式存取當地檔案系統他們不可以讀取或寫入資料到當地檔案系統不能取得檔案的任何相關資訊, 也不能查明檔案是

9 否存在或檔案的更新日期 3 applet 不能在用戶端機器執行其他程式, 也不能載入函式庫或定義原生函式呼叫 (Native method call) 4 applet 無法使用 System.getProperty() 取得有關使用者和用戶端機器的資訊, 但可以使用 System.getProperty 來取得目前的 Java 版本 5 applet 不能定義任何系統的屬性 6 在 Java1.1 以後,applet 不能建立或操作任何不屬於 applet 本身的執行緒 (Thread 或 ThreadGroup) 7 applet 不能定義或使用 ClassLoader SecurityManager ContentHandlerFactory SocktmplFactory 或 URLStreamHandlerFactory 的新實體 (instance), 只能使用已經存在的實體 8 applet 能連線的網路主機, 只能是該 applet 的來源處 9 最後, 也是最重要的一點,applet 不能接受來自用戶端的網路連線, applet 也不能在用戶端機器建立伺服器 Java Applet 是在網路上傳遞並由 local 機器執行的程式碼, 所以有安全上的顧慮, 因此 browser 會對 Applet 的能力加上一些限制, 例如不能存取 local 端的檔案等等, 然而這也對 Applet 的應用造成影響. Signed Applet 是加上數位簽章的 Applet, 簽章可以保障 Applet 不曾被修改過 ; 因此只要我們能確認簽章的正確性, 就可以相信這個 Applet 的來源, 而允許它存取一般 Applet 不能存取的系統資源 3-4 自我簽署 JDK 由於各瀏覽器對 Java 的支援不相同, 簽署方式也不相同, 同時若執行環境不同,Java 程式碼也會不相同基於以上原因,JAVA 有一套自我簽署 Java Signed Applet 的方法方法概述如下.. 工具 : 1 JDK HTMLConverter1.3 參數說明 : <certificatealias> - alias of certificate in keystore <KeyStore> - name of keystore file to create <storepassword> - password for keystore <keypassword> - password for private key in keystore <certificatefile> - name of file to create for exported certificate

10 <jarfile> - name of JAR to create <classes> - classes to put in JAR 一使用 keytool 產生一對金鑰 keytool genkey keyalg rsa alias <certificatealias> keystore <KeyStore> storepass <storepassword> keypass <keypassword> EX: keytool genkey keyalg rsa alias hiworldpw keypass hipw CK keystore ckstore storepass 二產生並匯出簽章 keytool export alias <certificatealias> keystore <KeyStore> storepass <storepassword> file <certificatefile>.cer EX: keytool export alias CK keystore ckstore storepass hiworldpw file CK.cer 三將簽章匯入至 JRE 的 keystore 由於 signed applet 是在 JRE 內執行, 因此必須將簽章匯入至 JRE 安裝位置內的 keystore cacerts, cacerts 一般在 C:\Program Files\Javasoft\JRE\1.3.1\lib\security\cacerts, 注意 cacerts 的密碼是 changeit keytool import file <vertificatefile>.cer alias <alias> keystore cacerts storepass changeit EX: keytool impot file CK.cer alias CK keystore cacerts storepass changeit 四產生 JAR, 並簽署 jar cvf <jarfile> <classes> jar i <jarfile> jarsigner keystore <KeyStore> storepass <storepassword> keypass <keypassword> <jarfile> <certificatealias> EX: jar cvf CK.jar CK.class

11 jar i CK.jar jarsigner keystore ckstore storepass hiworldpw keypass hipw CK.jar CK 五將 signed applet 放置在 HTML 內, 使用 HTMLConverter 轉換 java HTMLConverter 範例由於 Java Signed Applet 必須取得公開 CA 的認證, 才能保證此 Java Signed Applet 經過公開認證因為 Java Signed Applet 可以取得 local 端資料, 若沒有取得公開 CA 的認證, 任意下載憑證, 並執行該憑證認可的 Java Signed Applet 是很危險的因為本系統的測試環境並未取得公開 CA 的認證, 為了實驗的目的才採用自我發行憑證, 自我簽署的方式 3-5 FEDI 本系統是利用銀行網路作為傳輸資料與進行轉帳的功能金融電子資料交換 (Financial EDI), 簡稱金融 EDI 或 FEDI, 係指企業或個人利用電腦作業, 以特定的標準格式, 經由通訊網路與金融機構連線, 進行企業或個人之付款資金調撥及轉帳等金融服務第四章電子商務金融系統 (FSEC) 雛形 4-1 FSEC 之準備 Payment Gateway 所扮演的角色 Payment Gateway 是商店與金融銀行的溝通橋樑, 其所扮演的角色如以下所述 1 透過 Internet 接收商店的付款 (Payment)/ 請款 (Capture) 等 Electronic Commerce (EC) 需求訊息 2 將商店的 EC 需求訊息轉換為現行交易格式 ISO8583, 透過通訊介面傳送給金融銀行主機, 並接收其回應 3 將銀行主機的回應轉換為 EC 回應訊息, 透過 Internet 回傳給商店 Web Base 系統之方法由於要解決 SET 系統中持卡人需安裝電子錢包的問題, 所以我們採用 Web Base 的方式, 以及利用簽署認證的 Java applet 來達到此目標我們的方法是當持卡人進行交易時, 下載並執行由金資中心所簽署的

12 Java applet, 網路商店透過 applet 與網路銀行傳輸資料達到 Web Base 此目標的詳細步驟如下.. 當持卡人按下付款鍵, 將下載來自金資中心的簽署 applet, 網路商店使用收款銀行所給的 MAC(Message Authentication Code) [5] key, 來保證資料完整性 applet 去讀取持卡人存放在硬碟內的銀行帳號資料, 根據銀行帳號,applet 顯示持卡人可以使用的網路銀行選單當持卡人選擇好想要使用的轉帳銀行,applet 會把交易資料送至該網路銀行轉帳網頁, 並自動將帳號輸入進去, 網路銀行將顯示所收到的資料持卡人只需確認其資料是否正確, 再輸入密碼, 等候轉帳結果付款銀行將資料傳至收款銀行, 收款銀行驗證 MAC key 是否正確, 若不正確, 則拒絕該筆交易若正確, 則接受該筆交易付款銀行將轉帳結果告知持卡人由於各種瀏覽器的設定與環境不一樣, 所以 applet 必須要先去判斷使用者是使用哪一種瀏覽器而目前要執行簽署的 applet, 無論 Netscape 或是 IE 都必須以 plus-in 形態去執行 Java 執行作業環境 JRE(Java Runtime Environment), 這是很重要的電子商務金融系統 (FSEC) 名詞定義本系統中使用到兩個特殊的碼, 一個是代表某筆交易記錄的交易碼 = 商店代號 + 終端機代號 + 交易時間 + 交易金額 + 該筆交易序號 ; 另一個則為交易成功碼, 該碼的作用是讓使用者可利用此碼來查詢交易送貨情形 4-2 FSEC 交易 / 授權流程由於電子商務的交易過程不像傳統交易方式那般透明化, 再者也因網路交易過程的複雜, 所以預防與解決每個交易傳輸過程可能發生的錯誤, 是必須且重要的本金融系統利用銀行網路進行轉帳, 所以每筆交易情形都會記錄在付款與收款銀行, 因此該記錄可為持卡人與網路商店提供不可否認性的服務由於本系統傳輸過程是建置在 SSL 上, 所以也保證交易的私密性此外, 本系統強迫 applet 讀取磁碟資料, 所以間接利用 sandbox 來匡住惡意的 applet, 因為只有簽署的 applet 可順利讀取帳號, 所以可以確定此 applet 的可靠性, 並防止類似之前有人架設假的中國商銀網站, 取得持卡人帳號和密碼的事件發生以下是本系統的交易 / 授權流程

13 圖 ( 一 ) FSEC 交易 / 授權流程圖參考圖 ( 一 ), 詳細交易授權流程如下 : 1 持卡人在網路商店網頁選擇商品資料並填寫收貨人資料 ( 收貨人姓名連絡方式寄送地址等 ), 將資料使用 SSL 方式傳送資料至網路商店 2 網路商店收到訂單後, 產生交易碼, 並將交易碼加 MAC 當持卡人按下付款鍵後, 將下載金資中心簽署過的 applet, 而交易碼則透過此 applet 傳送給網路銀行持卡人在 applet 上選擇好付款銀行帳號後,applet 使用 SSL 方式將交易資料傳至該網路銀行 3 持卡人在網路銀行的網頁上確定該資料正確無誤後, 就輸入密碼以下步驟 4 至 8 為現行之 FEDI(Financial Electronic Data Interchange)[16] 作業流程 4 網路銀行將收到的資料傳送到 Payment Gateway,Payment Gateway 將資料轉換成在銀行網路中, 做為電子資料交換的特定格式後, 傳至付款銀行主機 5 付款銀行主機將該筆交易資料透過金資中心傳至收款銀行進行轉帳請求 6 收款銀行驗證該筆加 MAC 的交易碼是否正確, 如果正確無

14 誤, 則接受該筆交易, 如果是錯誤, 則拒絕該筆交易並透過金資中心傳送轉帳回應給付款銀行主機 7 付款銀行主機將轉帳回應傳送給 Payment Gateway 8 Payment Gateway 收到轉帳回應, 轉換成其格式並告知持卡人轉帳結果 9 若收款銀行接受該筆交易後, 將即時地告知網路商店已收到該筆交易金額 10 網路商店得知已收到該筆交易金額, 則告知持卡人, 完成交易並產生交易成功碼傳送給持卡人, 11 送貨發票寄送 12 持卡人可以使用交易成功碼查詢交易送貨情形第五章討論 5-1 安全分析消費者的保障由於消費者並未在商家網站輸入任何卡片資料與個人資料, 只告知商家收貨人資料因此能確保商家無法取得卡片資料也由於商家必須要與收款銀行連線取得收款銀行的 MAC key, 也藉由銀行認證商家的方式, 更增加消費者對商家的信任商家的保障由於只有在銀行有帳戶的消費者才可以進行交易, 如此便可更加認證消費者的身份也因此防止偽造消費者的可能性發卡銀行與收款銀行的保障由於銀行僅負責轉帳與傳輸資料, 因此與現行情形相比較之下, 並沒有增加負擔收款銀行亦可加上 onetime-password 的系統, 使商家與收款銀行的 MAC key 更有保障 5-2 SET SSL 與 FSEC 之比較由於 SET 是應用於網際網路上以信用卡為基礎的電子系統安全交易機制,SSL 僅是一個資料傳輸安全協定, 而 FSEC 是以 SSL 為基礎並配合銀行網路的電子商務金融系統由於 FSEC 是透過目前的 FEDI 做為網路購物時的付款方式, 所以亦可以使用金融卡做為支付工具, 並達到即時付款的需求也因 FSEC 是以 SSL 為基礎, 所以成本和 SSL 相當表 ( 二 ) 是 FSEC SET 和一般使用 SSL 做網路購物的比較 [ ]

15 支付工具表 ( 二 ) SET SSL 與 FSEC 之比較 FSEC SSL SET 金融卡信用卡金融卡信用卡信用卡網路安全機制說明信用卡付款方式, 說明除了一般我們使用說明 SET 是由 VISA & 與 SSL 一樣, 但是信用卡作為電子商 MASTER CARD 所兩者傳送卡片資料到銀行的方式與路徑則不相同重點是使用者可以使用任何自己的銀行帳號, 以金融卡作為交易工具, 而不限於必須有與該商家有簽約之銀行的帳號才行務的支付工具外, 現行市場, 當商家與簽約銀行協定後, 即可讓使用者使用金融卡作為交易,( 例如 : 世華銀行與中華電信等 ) 但當使用者沒有該簽約銀行的帳戶, 則無法使用金融卡發行推廣, 以信用卡為基礎作為支付工具傳輸資料過程採用傳輸資料過程採用傳輸資料過程採用 SSL SSL SET 重點是 :1 商家無重點是 :1 由於透由於 SET 是完整且法取得使用者任何過商家傳輸卡片資嚴謹的交易機制, 卡片資料與使用者料, 因此商家會有因此它能確保商家身分 2 使用者必使用者的卡片資無法取得使用者的須經過銀行確認身料, 因而有安全上卡片資料與交易資分 3 交易完成, 的風險 2 商家確料且使用者必須使用者可以即時知認使用者身分只能取得電子憑證的方道自己的帳號餘額使用商家自己認證式, 取得認證且與轉出交易金額 4 的方式, 因而會有交易完成後, 使用使用者可以從銀行冒用身分的事情發者可以即時知道帳與商家兩方面即時生 3 交易完成戶餘額與交易情知道交易狀況後, 使用者僅只能形從商家那得知交易重點是 :SET 所擁完成, 卻無法得知有的優點在 FSEC 自己帳戶餘額及其都有, 只是方法不真正轉出交易金額同, 然而在 SSL 中是否正確 4 使用者卻無法做到僅能從商家單方面

16 得知交易情形商家建置成本低成本僅需取得收款銀行低成本需建置與收款銀行的 MAC key 及一個連通的網路讓收款銀行傳輸資料的網頁即可銀行建置成本低成本低成本由於利用現有銀行收款銀行需即時將網路, 所以不需要交易資料傳輸至商新增任何軟體或系家統與 SSL 相同的是收款銀行需即時將交易資料傳輸至商家不同的是發卡銀行必須建置一個讓使用者登入的網頁高成本需安裝 SET 相關的軟體高成本銀行需要安裝 SET 的相關軟體, 並取得 CA 認證 5-3 電子商務金融系統 FSEC 的特色根據表 ( 二 ), 我們可以歸納以下幾點 FSEC 的特色 1 FSEC 可提供沒有信用卡之持卡人使用金融卡進行電子商務的服務 2 使用者可靈活運用各銀行的個人帳戶, 做即時付款或事後付款的方式, 做理想且有效率的理財 3 FSEC 不受作業系統影響 4 持卡人不需安裝電子錢包 5 持卡人卡片資料不會被網路商店知道 6 在 FSEC 中, 持卡人由銀行來實行認證比目前 SSL 付款機制, 交由網路商店以會員認證方式, 提供更嚴謹的認證方式 7 使用簽署過的 applet 代替電子錢包, 因此若有版本更新, 僅需由發行機構更換即可 8 FSEC 可用於即時募款證券交易 ( 不限定於特定銀行付款 ) 等, 將 SSL 用於電子商務的功能涵蓋進去, 並提供更嚴謹的安全性, 且提高其便利性 9 使用 FSEC, 所需成本比 SET 低, 而與 SSL 相當第六章結論及未來展望雖然 SET 提供高安全性, 可是卻因低便利性高成本而導致市場接受度不高, 而具備高便利性低成本及安全性的 SSL, 在整個系統架構上卻不如 SET

17 嚴謹本文旨在建置一電子商務金融系統, 以做為 SET 和 SSL 的平衡點, 同時能解決持卡人認證和網路商店可取得持卡人卡片資料等令人擔憂問題, 並與現實環境結合, 以提高此系統的可行性, 期望為電子商務提供更方便更安全的電子商務金融系統由於此電子商務金融系統 (FSEC) 是以 SSL 為基礎, 所以在網路交易過程中, 可能發生的法律交易等問題, 其解決的方式與目前的解決方式一樣如何利用科技創造更舒適便利的生活環境是大家的理想與目標希望將來能塑造一個無需攜帶現金或卡片, 甚至不需要這些設備就能進行交易的環境第七章參考資料 [1] Analysis of the SSL 3.0 protocol, [2] MASTERCARD, [3] Netscape, [4] One-Time Password System, [5] RSA FAQ [6] SET, [7] Signed applet, [8] SSL, [9] The SSL Protocol Version 3.0, [10] VISA, [11] 工研院電通所電子商務介紹網站, [12] 中華網路商圈, [13] 台灣 VISA, [14] 李國熙譯,Jason Hunter with William Crawford : JAVA Servlet 設計,O REILLY,1999 [15] 阮韻芳譯,Jonathan Knudsen: Java 密碼學,O REILLY,2000 [16] 財金資訊公司, [17] 陳則黎蘇偉慶 : SSL 及 SET 分析比

18 較, 資訊安全通訊第六卷第三期, ,pp [18] 張文旭 : SSL 協定簡介, 資訊安全第六卷第三期, ,pp [19] 電子商務示範網站 esales 購物網, [20] 戴天時譯,Elliote Rusty Harold: Java 網路程式設計,O REILLY,2000 [21] 盧銘仁 : 信用卡安全交易伺服系統在電子商務之廣用性設計與實作, 私立中原大學電子工程所碩士論文,1999

keystore weblogic.jks certreq.pem CA server.cer

keystore weblogic.jks certreq.pem CA server.cer \\\\\\\\\\\\ 2005 6 17 Windows 2000 Server WebLogic server 8.1 SP2 JDK1.4.2; IE 5.0 WebLogic8.1 www.cnca.net Guangdong Electronic Certification Authority 1...4 2...5 3...5 3.1...5 3.2 keystore weblogic.jks...5