1

以 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

ConsumerConsumer

MerchantMerchant

PaymentHandlerPaymentHandler

DeliveryHandlerDeliveryHandler

Merchant Customer

Care Provider

Merchant Customer

Care Provider

Accepts or makes payment for

Merchant

Makes purchases or obtains refund from

Merchant

Supplies goods or services

Resolves Consumer disputes and

problems

8

IOTP 互動模式

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

9

Authentication Exchange (Optional)

Offer Exchange

Payment Exchange

ConsumerConsumer MerchantMerchant Payment HandlerPayment Handler Delivery HandlerDelivery Handler

(Purchase Decision)

Delivery Exchange

Authentication Request

Authentication Response

Authentication status

Offer Request

Offer Response (invoice)

what is being paid

Payment Brand list

Payment Brand list Selection

Payment Organization

what is being delivered

Delivery Organization

Delivery Request (Part of invoice and receipt)

Delivery Response (Digital content data / Delivery note)

Payment Request (part of invoice , payment-specific data)

Payment Exchange (payment-specific data)

Payment Response (receipt, payment-specific data)

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 與其 XML 格式 (3/3)IOTP MessageIOTP Message

Trans Ref BlockTrans Ref Block

Trans ID Comp.Trans ID Comp.

Message ID Comp.Message ID Comp.

Signature BlockSignature Block

Signature Comp.Signature Comp.

Signature ElementSignature Element

Certificate ElementCertificate Element

Certificate Comp.Certificate Comp.

Error BlockError Block

Trading BlockTrading Block

Error Comp.Error Comp.

Error ElementError Element

Payment-specific dataPayment-specific data

Trading Comp.Trading Comp.

Trading ElementTrading Element

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

設計流程 (1/5)

12

3Consumer

Consumer

B2C Website

B2C Website

ObserverObserver

步驟一 : 買家向 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>

<!ELEMENT TransRefBlk (TransId, MsgId, RelatedTo*) > <!ATTLIST TransRefBlk ID ID #REQUIRED >

<Purchase Request Block>

<!ELEMENT PurchaseReqBlk (Mreq , Xreq) > <!ATTLIST PurchaseReqBlk ID ID #REQUIRED >

28

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

<!ELEMENT Mreq EMPTY >

<!ATTLIST Mreq

ID ID #REQUIRED xml:lang NMTOKEN #REQUIRED PID CDATA #REQUIRED N CDATA #REQUIRED Pb CDATA #REQUIRED

CPi CDATA #REQUIRED

ADRC CDATA #REQUIRED

IDBCW CDATA #REQUIRED

IDOBS CDATA #REQUIRED >

29

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