以 IOTP 建構符合行動通訊實務的 B2C 電子商務安全研究

1. 以IOTP建構符合行動通訊實務的B2C電子商務安全研究以IOTP建構符合行動通訊實務的B2C電子商務安全研究 報告者 : 劉岳鑫

2. Outline • 簡介 • IOTP介紹 • IOTP的發展情形 • 將IOTP應用於行動商務 • 設計流程

3. 簡介(1/2) 近年來由於資訊技術與網路科技的爆炸性發展，網路交易已成為大眾喜愛的一種交易方式，因此造就了電子商務的興起。電子商務成長的速度十分快速，但是卻無法有效整合出一套標準程序，使得電子商務的環境日趨複雜。於是IETF組織便針對電子商務制定了一套IOTP互動式架構，在此架構的規範下，網路交易將可以有一個統一的標準流程與資料交換格式。

4. 簡介(2/2) 然而IOTP所考慮的只是B2C的電子商務模式，若要將其應用於現在熱門的行動商務上，勢必要就行動商務的需求來檢視IOTP的整體架構，因此我們便依據IOTP version2的需求，對其在行動商務不足的部份，重新設計，希望能將IOTP應用於行動商務。

5. Internet Open Trading Protocol (IOTP) IOTP是 IETF組織針對電子商務行為制訂出一套互動 架構，目前的版本為1.0，在IOTP version 1中所考慮的商業模式為B2C，它是一個付費系統獨立的架構,也就是將現有的付費系統如: SET、Mondex 、CyberCash、DigiCash、GeldKarte直接套用到架構中使用，在此架構的規範下，網際網路上進行交易買賣將有統一且公開的標準流程與資料交換格式。

6. IOTP version 1架構 首先，在IOTP v.1所考量的商業模式中，一共有Consumer、Merchant、Payment Handler、Delivery Handler、Merchant Customer Care Provider等五種相關的交易角色(Trading Roles) 。

7. Makes purchases or obtains refund from Merchant Merchant PaymentHandler Accepts or makes payment for Merchant Consumer DeliveryHandler Supplies goods or services Merchant Customer Care Provider Resolves Consumer disputes and problems

8. IOTP互動模式 在IOTP的各個角色之間，總共有四種交易互動(Trading Exchange)模式，分別是Offer、Payment、Delivery、Authentication，各種角色透過這些資料交換過程，達成網際網路上的交易買賣，整個流程如下圖所示：

9. Consumer Merchant Payment Handler Delivery Handler (Purchase Decision) Authentication Exchange (Optional) Authentication Request Authentication Response Authentication status Offer Exchange Offer Request Offer Response (invoice) Payment Exchange what is being paid Payment Brand list Payment Brand list Selection Payment Organization Payment Request (part of invoice , payment-specific data) Payment Exchange (payment-specific data) Payment Response (receipt, payment-specific data) Delivery Exchange what is being delivered Delivery Organization Delivery Request (Part of invoice and receipt) Delivery Response (Digital content data / Delivery note)

10. IOTP交易處理 在IOTP v.1所定義B2C的交易買賣過程中，會進行下列八種的交易處理(Transaction)： • Purchase：消費者向商家購物(包含Offer、Payment、Delivery)。 • Value Exchange：允許搭配組合不同的金流機制。 • Refund：支援交貨後付款的機制。 • Withdrawal：支援電子現金機制之提領程序。 • Deposit：支援電子現今機制之存款程序。 • Authentication：任何角色若有必要可對其他角色要求進行身份認證程序。 • Inquiry：任何交易程序的狀態皆可查詢。 • Ping：一方可判別另一方是否採用IOTP協定。

11. IOTP Message與其XML格式(1/3) 要完成交易，各個角色間的互動與資料交換是很重要的環節，因此必須定義出一個標準來讓大家遵循，使得角色間的互動與資料交換變的更方便更容易，所以XML格式就是一個很好的選擇。

12. IOTP Message與其XML格式(2/3) IOTP message其XML格式內的欄位類別，主要分為Transaction Reference Block、Signature Block、Error Block、Trading Block四大區塊，在逐一制訂出各個欄位，如下圖所示：

13. IOTP Message Trans Ref Block Trans ID Comp. Message ID Comp. Signature Block Signature Comp. Signature Element Certificate Comp. Certificate Element Error Block Error Comp. Error Element Payment-specific data Trading Block Trading Comp. Trading Element IOTP Message與其XML格式(3/3)

14. IOTP的發展情形(1/2) IOTP是一個真正開放的標準，不過自2000年提出之後，到目前為止卻沒有被廣泛使用，看不到有哪些商務網站或公司用它來建置電子商務系統。於是，有些學者在這方面做了探討，發現主要的原因如下：

15. IOTP的發展情形(2/2) • 1. IOTP v.1的設計，付款機制可採用任何已存在的標準(例如SET、Modex、CyberCash、DigiCash、GeldKarte...等)，完全沒有任何與付款機制的介面設計，也無從規範金流運作的安全與效率，結果造成與付款閘道協同運作的不方便且低效率。因此IETF正廣徵建議，在將來的IOTP v.2規劃解決此一問題，更具體的設計付款機制的介面。 • 2. IOTP v.1的設計，一開始即強調適用大部分的交易買賣，以通用性為主要考量，而不考慮電子商務模式的差異性。也就是說，IOTP比較適合B2C的交易模式，至於B2B、C2B、C2C、甚至是P2P的交易模式，其實有許多不適合套用到IOTP的程序。因此IETF也廣徵建議，在將來的IOTP v.2規劃納入更多的交易模式設計，更適切設計出新的應用流程與資料格式。

16. IOTP version2(1/3) IOTP目前的版本為version 1，然而IETF組織其實早有打算推出version 2 ，可是version 2到目前為止還沒有正式出現，雖然還沒推出，但version 2的需求已經條列出來，基本上version 2希望能擴展version 1現有的網路交易整合能力，並增進version 1的功能，且不會對version 1的內容做出很大的改變。IOTP version 2的需求如下:

17. IOTP version2(2/3) • Version 2的內容與功能要相容於version 1 。 • 在IOTP message格式中加入Offer Request Block，並描述其相關定義。 • 提供更好的解決糾紛方案。 • IOTP version 2不再是直接套用付費協定，而是可以判斷其是否安全。 • 在IOTP Message的trading block中增加新的項目與屬性，用來加入本來所沒有的功能，甚至發展出一個全新的trading block。

18. IOTP version2(3/3) 於是，我們發現了一些學者發表了這方面的研究，希望能在IOTP v.2正式推出前，為其提出更多的應用，例如將IOTP應用於數位商品的交易上而加入DRM的設計，就是根據version 2需求中所提到的設計新的trading block來加入新的功能，因此我們也可以依據version 2的需求，以IOTP來設計不同的應用。

19. 將IOTP應用於行動商務(1/2) 由前面的介紹，我們知道IOTP是針對電子商務的行為來設計的，但由於目前行動商務是十分熱門的，因此我們試著將一個完整的行動商務架構與IOTP結合，依照IOTP v.1的設定與v.2的需求，希望能將IOTP應用於行動商務的領域上。

20. 將IOTP應用於行動商務(2/2) 接下來我將以例子來說明設計的過程，在學長的架構中分為議價、物流、付款三個階段，我以議價階段來說明。

21. 2 Consumer 1 B2C Website Observer 3 設計流程(1/5) • 步驟一: 買家向B2C網站提出購買請求。 • 步驟二: BCW 產生一個交易序號並對此購買 • 請求簽章 。 • 步驟三: 在確認買家的購買請求和BCW的簽 • 章後，observer幫BCW簽章。

22. 設計流程(2/5) <原架構> 　　　在步驟一中買家要傳送一個購買請求給BCW，這個購買請求包含有商品ID、數量、買家希望購買的價格、買家的暱稱、貨物送達的地址、BCW和OBS的ID，除此之外，買家還會為OBS產生一個認證訊息然後再一起傳給BCW。

23. 設計流程(3/5) <針對IOTP的設計> 我們發現架構中所有步驟不外乎是由將資料組合成新的資料、藉由運算產生訊息、簽章、驗證簽章、確認資料、傳送資料這幾個動作組成的，因此我們將這些動作分別定義為Chain()、Math()、Sign()、Verify()、CheckData()、SendData()這幾個Function。

24. 設計流程(4/5) (1)在步驟一中，買家會將購買請求Mreq　傳給BCW，其中Mreq包含的資訊有商品ID、商品數量、 買家希望購買的價錢、買家的匿名、買家的住址、購物網站ID、Observer的ID。 C.Chain()--->Mreq C.SendData(Mreq) 表示買家傳送購買請求 (2)然後C會產生一個認證訊息Xreq給observer C.Math(Mreq)---> Xreq表示此動作 (3)最後C將Mreq及Xreq傳給BCW C.SendData(Mreq , Xreq) 表示此動作

25. 設計流程(5/5) 接著我們必需定義出此步驟中所要傳遞的IOTP Message的格式，在此我們參考IOTP v.1關於傳遞的message格式設計後發現，在Trading Block中已經定義好的Block並不能滿足我們在這裡設計的需求，所以我們根據IOTP v.2需求裡提到可以增加新的tag、block、attribute，在這裡增加新的Purchase Request Block，因此，我們將此步驟所傳送的IOPT message格式設計如下:

26. <!ELEMENT IotpMessage ( TransRefBlk, ( PurchaseReqBlk ) ) >

27. <Transaction Reference Block> <Purchase Request Block>

28. 在Purchase Request Block中的Mreq為購買請求，因此必須再 額外定義其包含的內容，定義如下:

29. 麻煩請老師及各位學長多多指導,謝謝～！